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ABSTBACT 

This  thesis  reports  on  the  design  and  implementation  of 
a  simulation  of  the  Signal  Processor  In-erface  to  the 
AN/SPY-1A  Phased  Array  Radar  Controller.  Inherent  to  the 
simulation  is  the  development  of  a  representative  time 
sensitive      database      of      the      targeting      environment.  The 

programming  language  Ada  was  utilized  as  a  program  devslcp- 
ment  language  in  the  design  for  the  database.  The  developed 
Target  Database  utilizes  the  20  mega-byte  REMEX  Data 
Warehouse   3200    memory  storage   unit.  The   simulation   of   the 

Signal  Processor  Interface  will  allow  real  time  testing  of 
the  Naval  Postgraduate  School's  AN/SPY-1A  Radar  Controller 
System   Model. 
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I.    INTRODUCTION 

A.        BACKGROUND 

The  AEGIS      System        is        the        Navys  multi-faceted 

shipboard  weapon  control,  decision  making,  and  surveil- 
lance system.  The  engineering  model  began  testing  on  the 
"Norton  Sound"  in  1977  and  the  AEGIS  System  joined  ths  Fleet 
on  board  the  "Ticonderoga"  in  1982.  To  date,  the  AEGIS 
System  represents  the  newest  fielded  technology  in  the 
Fleet      and      possibly   in        the      world.  Since  every      design 

effort  must  at  some  time  in  the  design  determine  what  the 
target  hardware  will  be  for  the  system,  the  result  is  that 
all  "new  systems"  do  not  in  fact  utilize  the  most  current 
electronic  advances.  In  addition,  the  further  design, 
testing,  and  linking  of  the  many  separately  developed 
and  tested  modules  further  increases  this  unaviodable  hard- 
ware gap.  In  the  case  of  the  AEGIS  System,  this  is 
particularly  true  since  we  have  seen  a  technological  revo- 
lution occur  during  it's  development.  The  Large  Scale 
Integrated  Circuits  (LSI)  ,  and  now  the  Very  Large  Scale 
Ingrated  Circuits  (VLSI)  are  common  in  our  off-the-shelf 
technology.  The  Naval  Postgraduate  School  AEGIS  Modeling 
Group  has  been  investigating  the  use  of  new  off-the-shelf 
VLSI  technology  that  could  provide  significant  savings  in 
money  and  space  while  still  fulfilling  the  system  require- 
ments of  the  AEGIS  system.  The  AEGIS  Modeling  Group 
decided  early  in  their  study  and  emulative  modeling 
to  choose  the  AN/SPY-1A  Phased  Array  Radar  Controller  as  a 
modeling  subset  of  the  AEGIS  system.  The  SPY-1A  Radar 
represents  a  sufficiently  difficult  and  real  time 
sensitive   module        of       the      AEGIS  system   such     that      if      it 
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can  b€        successfully      emulated,  then        it      should     be 

possible  to  similarly  build  the  other  modules  comprising  the 
total    AEGIS    system. 

The  AN/SPY-1A  is  a  complicated  and  extensive  system  in 
its'  cwn  right.  The  two  primary  modules  of  the  SPY-1A  Radar 
Controller  are  the  Radar  Scheduler  and  the  Track  Processor. 
Previous  thesis  work  has  been  done  to  model  these  two 
modules  by  Grant  [Ref.  1]  and  Cech  [Ref.  2]  respectively. 
In  addition,  the  two  systems  that  dspend  on  the  AN/SPY-1A 
for  data  -  the  Weapon  Control  Sys-em  (WCS)  and  the  Command 
and  Decision  System  (CD)  -  have  been  simulated  by  Boone 
[Ref.    3]   in     his  thesis.  The   Signal      Processor    module      is 

another  module  to  be  simulated  such  that  the  NPS  SPY-1A 
Model  subset  can  be  fully  interfaced  and  tested  for  real 
time      capability      and     logical      functioning.  The      initial 

design,  development,  and  target  environment  simulation  of 
the  SPY-1A  Signal  Processor  Interface  is  the  intent  of  -chis 
thesis. 

B.        DISCLAIMER 

Many  terms  used  in  this  thesis  are  registered  trademarks 
cf  commercial  products.  Rather  than  attempting  to  cite  each 
individual  cccurrance  of  a  trademark,  all  registered  trade- 
marks appearing  in  this  thesis  will  be  listed  below, 
following   the  firm    holding    the   trademark. 

Intel   Corporation,    Santa   Clara,    California: 
Intel,    Intel   8086,    iSEC    86/12A,    MULTIBUS 

Digital   Research  Corporation,    Pacific   Grove,    California: 
CP/M,    CP/M-86,     PL/I-86,     PL/I-80,     ED,    RASM-86,     LINK86, 
DDT-86 

EX_CEIL_C   Corporation,   Irvine,    California: 
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REMEX   Data    Warehouse 

MicroPro    International,    San    Rafael,    California: 
Wordstar 

Department   of  Defense,   Washington   D.C.: 
Ada 

Micropolis    Corporation,    Chatsworth,    California: 
Micrcpolis 

Lear    Siegler,    Inc.,    Anahiem,    California: 
ADM- 3 A 

C.       PORPCSE    OF    THIS    THESIS 

The   broad      direction   of    the   Signal      Processor    simulation 
is   threefold: 

1.  Emulate  the  SPY_1A  Signal  Processor  using  the  Remex 
Data  Warehouse  (a  20  megabyte  fixed  Winchester  tech- 
nology disk    system)  . 

2.  Ee  able  to  emulate  the  signal  processor  functions  to 
provide  a  real  time  test  environment  for  the  SPY-1A 
Model. 

3.  He  able  to  use  the  simulation  to  nest  the  logic  of 
the    NPS    SPY-1 A   Model. 

These  bread  objectives  were  further  subdivided  into  tasks  to 
develop  a  target  database  module  and  two  system  testing 
modules.  The  first  system  testing  module  will  emulate  the 
hostile  environment  of  targets  utilizing  a  pr e-developed 
target  database  while  the  NPS  SPY-1 A  Model  is  being  run/ 
tested  for  real  time  operations.  This  model  is  designed  to 
respond  as  quickly  as  possible  to  a  dwell  command  from  the 
Badar  Scheduler  Module  with  an  appropriate  data  output  to 
the  Track  Processor  Kcdule,  to  allow  an  accurate  test  of  the 
speed   of      the  overall     SPY-1A    Model.  This    design      will   be 
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herein  referred  to  as  the  "Static  Model".  The  second  system 
will  be  used  to  test  the  logic  of  the  internal  SFY-1A 
modules,  and  will  not  be  constrained  to  real  time  run 
requirements.  It  will  display  a  target  environment  as  it 
developes  and  changes  over  time,  and  allows  the  user  to 
initiate  and  change  the  environment  as  he  desires.  This 
design  will  be  herein  referred  to  as  the  "Dynamic  Model". 
The    tasks   fcr  each   of  the   Modules   are   as   follows: 

TARGET    DATABASE: 

1 .  Create  targets. 

2.  Develop  target  tracks  and  record  those  target  loca- 
tions on  the  respective  track  ar  descrete  time  inter- 
vals   in    the    database. 

3.  Modify  and  Delete  targets  and  target  dadta  on  the 
database. 

STATIC    Model: 

1.  Interface  database  access   with    NFS    SPY_1A    Model 

2.  Monitor  the  I/O  interface  during  tasting  without 
detracting   frcm  the    real  time    environment 

DYNAMIC    Model: 

1.  Allow  interactive  changes  to  be  made  to  the  database 
during  runtime 

2.  display  the  tracks  in  the  database  as  the  simulation 
runs 

The  scope  of  this  thesis  extends  primarily  to  the  Target 
Database  and  Static  Model  development  and  implimentation, 
although  the  overall  design  structure  is  such  that  the 
Dynamic  Model  can  encompass  and  utilize  the  modules  devel- 
oped   herein. 
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D.        TBESIS    ORGANIZATION 

The  thesis  is  organized  into  four  chapters.  The  computer 
code  developed  tc  implement  the  system  is  contained  in  the 
following   appendices.  The   first   chapter   covers      the    back- 

ground cf  the  Aegis  Project  at  the  Naval  Postgraduate 
School,  the  basic  direction  for  this  thesis,  and  thesis 
organization.  The  second  chapter  covers  the  design  of  the 
Signal  Processor  Interface  Module.  It  will  discuss  the 
overall  considerations  for  the  design,  the  interfaces 
neccessary  between  the  Signal  Processor  and  the  ether 
modules  previously  developed,  and  the  specific  design  for 
the  Target  Database  and  Static  Model.  The  programming 
language  Ada  was  utilized  as  a  Program  Design  language  (PDL) 
in  the  development  of  a  design  for  the  Target  Database  and  a 
Dynamic  Mcdel.  The  third  chapter  will  discuss  the  implemen- 
tation cf  the  design  for  the  Signal  Processor  Interface 
Module.  Translation  considerations  when  Ada  is  used  as  a 
PDL  and  the  implementation  language  is  PL/I  are  highlighted. 
The  modules  that  make  up  the  Target  Database  and  the  Static 
model      are   discussed      in      detail.  Finally,      Chapter      four 

presents  some  conclusions  on  the  work  involved  in  the  design 
and  ittple me  station  of  the  Signal  Processor  Interface  Module 
as  it  is  now,  how  it  might  be  utilized  and  changed  by  future 
Aegis  Group  members,  and  what  the  next  logical  steps  should 
be  toward  the  complete  simulation  of  the  critical  paths  of 
the    SPY-1A    Phased   Array   Radar    Controller. 
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II.    DESIGN   OF    THE    SIGNAL    PROCESSOR    SIMULATION 

A.       OVERALL    CONSIDERATIONS 

1 .      Designing  for  Change 

Tc  provide  the  desired  future  maintainability  and 
flexibility  as  a  simulative  and  emulative  instrument,  it  is 
neccesary  tc  design  the  Radar  Signal  Processor  Simulation 
with  the  capability  for  change.  The  latest  concepts  of  good 
software  engineering  principles  explain  -ha-  forseeable  and 
ncn-f orseeable  changes  are  sure  to  be  applied  to  any  soft- 
ware engineering  project,  but  especially  in  -chose  cases  were 
the  program  being  developed  is  being  separately  designed  and 
implemented  to  become  part  of  a  larger  system.  To  provide 
that  capability,  the  designer  and  programmer  must  from  the 
start  try  to  separate  those  items  that  are  likely  tc  be 
changed  and  use  the  concepts  of  clear  documentation  and 
structured  programming  to  make  it  easier  for  the  system 
users  and  maintainers  to  incorporate  changes.  The  decisions 
that  are  made  in  modularity  and  implementation  must  be  docu- 
mented tc  enhance  the  under standability  of  the  system.  As 
much  as  possible,  the  assignment  of  parameters  and  constants 
should  be  clustered  or  at  least  positionally  standardized 
within  mcdules  to  allow  ease  in  finding  them  and  changing 
them.  The  design  concept  of  information  hiding  needs  to  be 
utilized  such  that  enhanced  versions  of  specific  implementa- 
tions can  be  easily  substituted  without  causing  major 
changes  throughout  the  other  modules  that  constitute  the 
overall    design. 
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2  .      Designing   for  Extensibility 

A  part  of  designing  for  change  is  the  consideration 
of  and  provision  for  extensions  to  the  basic  design  one  may 
provide.  It  is  important  to  consider  the  critical  items  in 
the  design,  and  yet  still  allow  for  the  addition  cf  ether 
modules  that  may  provide  desired  functions  for  future  users 
of  the  system.  One  way  to  provide  this  capability  in  a 
design  is  in  utilization  of  a  tree  like  structure  that  will 
allow  the  addition  of  other  branches  at  any  node  of  the 
hierarchy.  In  so  doing,  the  designer  offers  the  maximum 
flexibility  in  the  basic  design,  and  enhances  future  main- 
tainability and  changability,  while  providing  for  the 
unf orseeatle. 

3 .      Modular    Design 

Incorporating  the  design  principle  of  modularity 
will  provide  the  basis  for  both  changability  and  extensi- 
bility. Choosing  modules  in  the  program  -chat  describe  a 
concise  function,  and  interface  with  each  other  without  side 
effects  will  enhance  the  under standability  of  the  design  and 
the  resultant  code.  Utilizing  a  design  methodology  that 
incorporates  the  principles  of  top-down  design  and  assists 
in  the  partitioning  of  a  complex  problem  into  intellectually 
addressable  sub-prcblems  will  naturally  produce  good  modu- 
larity. Eoochs'  "Object-Oriented  Design"  methodology 
[Ref.  4]  discussed  in  detail  in  Section  II. C  and  Appendix  E 
provides  these  attributes.  The  design  of  both  the  target- 
database  and  static  model  incorporates  many  of  these  princi- 
ples limited  only  by  the  author's  designing  and  programming 
prowess. 
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B.       INTERFACES 

In  th€  thesis  work  done  by  Riche  and  Williams  [Ref.  5]r 
the  overall  design  and  modular  interfaces  were  discribed  and 
defined  fcr  all  future  SPY-1A  Controller  Module  development. 
However,  since  their  design  incorporates  the  development  of 
all  the  modules,  and  the  project  at  this  stage  of  implemen- 
tation has  only  developed  the  most  critical  modules  required 
to  emulate  a  basic  subset  of  the  real  SPY-1A  Radar 
Controller,  the  interfaces  they  developed  are  not  completely 
appropriate.  To  interface  with  the  dwell  commands  passed  by 
the  Radar  Scheduling  module  [Ref.  1]  and  to  pass  feedback 
that  can  be  understood  by  the  Track  Processor  module 
[Ref.  2],  the  Signal  Processor  Module  must  logically  incor- 
porate the  Radar  Output,  Radar  Return,  and  Beam 
Stabilization  modules.  Therefore,  the  interface  utilized 
for  input  is  table_5  8  ("Common  Memory  Interface  between  the 
Radar  Scheduling  and  the  Beam  Stabilization  modules") ,  and 
the  interface  used  to  output  is  table_8  ("Common  Memory 
Interface  between  the  Beam  Stabilization  and  the  Track 
Processor  modules")  [Ref.  5].  Not  only  will  this  extension 
of  the  logical  interface  for  the  Signal  Processor  make  the 
future  work  cf  interfacing  the  modules  easier,  but  it  makes 
the  present  design  fcr  the  Signal  Processor  Interace  Module 
easier  tc  implement.  The  chosen  interfaces  will  allow  the 
signal  piccessor  model  to  receive  and  send  target  data  in 
terms  of  cartesian  coordinates  rather  than  the  lengthy  and 
complicated  codes  that  specifically  tell  the  signal 
processor  where  to  point  its  beams.  Tables  I  and  II  show 
the    respective    interfaces. 
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TABLE    I 

— 1 

Signal    Processor   Output    Interface 

/* 

OWNER:     AEGIS     MODELLING    GROUP 

DATE    OF    LAST    UPDATE:    28    OCT    81 

MODULE    TYPE:    TABLE 

PURPOSE:    COMMON    MEMORY   INTERFACE 

NAME:     E    TO    P    TABL 

*/ 

/* 

THIS    TABLE    INTERFACES    BETWEEN    THE    BEAM    STABILIZATION 

PRCCESS    AND    THE    TRACK    PROCESS 

*/ 

1 

! 
I 

! 

declare 
1    B   tc    P  tabl     static  external, 

2    x   su5  s                                              fixed    bin | 
2   y~sub"~s                                             fixed   bin i 
2    z   sub  s                                               fixed   bin i 
2    face  id                                             fixed   bin i 
2    dvl    ldx                                              fixed   bin  I 
2    trk_num                                             fixed   bin* 

;151 

15 

l     initial 
i    initial i 
i     initial < 
i    initial 
initial i 
initial \ 

0 

i°; 

0' 

0' 
0( 

I 
1 

I 
)  ,\ 

rl 
,   1 
,1 
,   \ 

;  I 

/*    END    OF   TABLE    */ 

1 

! 

C.        USE    CF    ADA     AS    A    PROGRAM    DESIGH   LANGUAGE 

Grady  Beech  [Ref.  4]  has  proposed  a  software  engineering 
design  technique  he  terms  "Object-Oriented  Design". 
Although  his  chosen  name  for  the  design  methodology  may  be 
unfortunate  considering  the  controversy  raised  by  the  ambi- 
guous term  "Object",  and  the  past  use  of  the  term  in  refer- 
ence to  the  Smalltalk  programming  language,  the  design 
methodology  itself  works  well.  Using  the  new  Department  of 
Defense        programming        language      Ada,  the        purpose        of 

Object-Oriented  Design  is  to  produce  logical,  efficient, 
highly  readable  and  understandable  code  that  accurately 
reproduces  the  real  world  problem  in  the  computer  space. 
Ada    is   utilized    as    a    program   development   language    because  of 
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TABLE   II 
Signal   Processor   Input    Interface 


/* 

OWNER:    AEGIS     MODELLING    GROUP 

DATE    OF    LAST    UPDATE:    2    NOV    81 

MODULE   TYPE:     TABLE 

PURPOSE:     COMMON    MEMORY   INTERFACE 

NAME:     E    TO    B    TABL 

*/ 


/* 

THIS    TABLE    IS    THE    INTERFACE    BETWEEN 
ANE    BEAM    STABILIZATION    PROCESSES 
*/ 


FADAR  SCHEDULING 


declare 
1  R  to_B  t 
2  search 
3  a  si 
3 
3 


abl  (10) 

dwls, 
I 
elev 
time 

4  msb 

4  lsb 
3    dwl    idx 
3    beam_purpose 
3    aloha   delta  cos 
3   beta    3elta_cos  o 
3    face~assign 
trk    burn  thru, 
3    tyt>a_dwl 
3   stabe  coords, 

4  x    stbl 

4   y~stbl 

4   z    stbl 
3    dxl_Tdx 
3    time, 

4   msb 

4   lsb 
3    beam_curpcse 
3    alpha "delta__cos 
3    beta    clelta   cos  o 
3    face~assign 


static   external, 


cff set 
ffset 


fixed 
fixed 

fixed 
fixed 
fixed 
fixed 
fixed 
fixed 
fixed 


bin  (15) 
bin  (15) 


initial  (0 
initial 


bin 
bin 
bin 
bin 
bin 
bin 
bin 


15) 


?! 


15) 

V 


H 


initial 
initial 
initial 
initial 
initial 
initial 
initial 


M 


fixed  bin  (7)   initial  (0) 


offset 
ffset 


fixed 
fixed 
fixed 
rixed 

fixed 
fixed 

fixed 
fixed 
fixed 
fixed 


bin  (15 
bin(15 
bin  (15 
bin(7) 


bin 
bin 
bin 
bin 
bin 
bin 


ill 

15 

7) 


initial 
initial 
initial 
initial 

initial  (0' 
initial  (0* 
initial  (0 
initial  (0' 
initial  (0' 
initial  (0 


/*  END  OF  TABLE  */ 


its  capabilities  in  the  production  of  highly  structured  and 
modularized  algorithms.  It  also  has  the  nice  feature  of 
separating  the  specifications  for  the  modules  utilized  in 
the  design  from   the  actual  methods  used   for  implementation 


19 


cf  these  modules,  and  thus  provides  the  designer  with  an 
ability  to  postpone  the  implementation  decisions  for  as  long 
a  time  as  convenient  during  the  design  phase.  This  feature 
was  particularly  important  since  the  programming  language 
FL/I-86  was  going  to  he  used  for  actual  implementation,  and 
it  was  intuitively  felt  that  some  design  changes  and  conces- 
sions might  have  to  be  made  even  at  the  highest  levels 
because  cf  the  differences  in  the  large  scale  data  struc- 
tures  provided    by  the  two   languages. 

Object-Oriented    Design      methodology   is    broken      down   into 
three    basic   steps: 

1.  Define  the  Problem 

2.  Develop  an  Informal  Strategy 

3.  Formalize  the  Strategy 

"Defining  the  problem"  involves  the  development  of  a  concise 
paragraph  in  English  that  specifically  outlines  the  real 
world  problem.  "Developing  an  Informal  Strategy"  is  to 
develop  an  English  paragraph  that,  as  clearly  and  concisely 
as  possible  describes  how  one  will  solve  the  problem.  This 
second  step  is  really  the  iosi  difficult  part  of  the  method- 
ology, since  the  resultant  success  of  the  design  rests  on 
how  well  this  can  be  accomplished  by  the  designer.  The  last 
portion  "Formalize  the  Strategy"  is  where  the  algorithm 
begins  to  take  shape.  First,  the  designer  must  pick  out  the 
proper  nouns  that  describe  the  "objects"  of  the  solution 
strategy.  Those  objects  are  discribed  in  terms  cf  major 
objects  and  attribute  objects.  Next,  the  Informal  Strategy 
is  again  scrutinized,  this  time  to  pick  out  the  verbs  that 
represent  the  "operations"  utilized  in  the  solution  stra- 
tegy. These  operations  are  then  grouped  with  the  objects 
they  logically  affect  in  the  informal  strategy.  Bcoch  then 
would  have  the  designer  draw  an  object-oriented  system  graph 
depicting  the  objects  as  Ada  "packages"  and  the  operations 
as    Ada   procedures      and  functions   within   the      packages.        The 
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object-oriented  system  graph  describes  the  hierarchial 
interfaces  between  the  structures.  Booch  typically  includes 
an  Ada  "subprogram"  as  a  controlling  program  that  utilizes 
the  developed  packages.  Finally,  the  package  specifications 
are  written  in  Ada  utilizing  the  previously  developed 
object-oriented  system  graph  as  a  guideline  for  the  inter- 
facing and  specific  procedure  specification  development. 
This  was  done  in  the  design  of  a  "Dynamic"  model  and  Target 
Database  system  and  is  specifically  shown  in  Appendix  E  for 
future   use    by  the   AEGIS    Modeling   Group. 

D.       THE    DATABASE 

Using  the  Ada  design  as  a  basis,  the  Target  Database  was 
designed  for  implementation  in  the  PL/I  and  ASM-86 
languages. 

1 •      Interfacing    and   Sto  rage 

The  AEGIS  Modeling  Group  experimental  computer 
depends  en  a  32  k  byte  "common  memory"  board  on  the  MULTIEUS 
to      pass   messages.  The      common      memory    board      is      further 

utilized  for  the  commands  to  the  REMEX  Data  Warehouse  20 
mega-byte  storage  system  and  the  buffered  data  items  to  be 
written  en  and  retrieved  from  the  HEMEX.  A  mapping  of  how 
the  cemmen  memory  is  currently  partitioned  is  shown  in 
Figure  2.1  The  segmented  memory  base  for  the  common  memory 
is    0E000      hex  and      offsets    are      as  shown.  The    REMEX      Data 

Warehouse  is  also  connected  to  the  MULTIBUS  and  data  is 
transfersd  to  and  from  it  in  response  to  the  formated 
messages.  The  processes  for  the  operations  of  the  REMEX  are 
discussed  in  detail  in  the  thesis  work  done  by  Almguist  and 
Stevens  [Ref.  6]  and  in  the  appropriate  manuals  [Ref.  7], 
The  basic  message  fcrma-  utilized  for  this  thesis  is  the 
read/write    format  [Ref.    8]     (as   specified    in   Figure    2.2). 
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Figure    2.1         Common   Memory   Map. 

2  •      Design    Decisions 

The  Ada  design  for  the  Target-Database  resulted  in  a 
system  that  protects  and  hides  the  actual  database  and  how 
it  was  implemented  from  the  user.  In  an  effort  to  incorpo- 
rate that  design  feature  in  the  PL/I-86  implementation,  the 
concept   of      using  a      specific   module      to   perform      all   target 
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Figure   2.2        BEMEX   Read/Write    Message   Format. 

data  conversion  to  an  appropriate  output  message  forma-:,  and 
then  to  perform  the  operations  to  place  that  formated 
message  in  the  PEMEX  was  conceived.  This  module  is  named 
Bld_datafcase.  Not  only  does  it  perform  those  tasks  just 
mentioned,  but  because  of  it's  modularity,  it  provides  for 
future  changes  should  the  method  of  storing  the  database  be 
modified,  or  the  hardware  device  utilized  for  storage  be 
replaced.  In  addition,  the  decision  was  mads  to  stcre  only 
the  messages  to  be  utilized  for  output  on  the  REMEX,  rather 
than  storing  both  the  initial  target  data  that  produced  the 
messages   and  the   messages   themselves.  The   reason    for   this 
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decision  is  to  provide  the  fewest  number  of  REMEX  data 
seeking      operations    during      the  run      of      a    simulation.  By 

utilization  of  a  data  structure  on  the  current  iSBC  86/12A 
in  RAM  (Random  Access  Memory)  to  pre-build  the  proper 
sequence  of  messages,  only  a  write  command  will  be  required 
to      retrieve  data      from   the      REMEX.  Although   this      method 

requires  more  execution  time  during  the  creation  of  the 
Target-Database,  very  little  execution  time  is  consumed 
during  the  emulation.  The  method  utilized  for  creation  and 
modification  requires  the  partial  re-building  of  the  data- 
base   for   each   change    made  to   the   Target-List   of   data. 

3  .      D  e  s  i  qn 

The  resultant  design,  modularized  for  implementation 
in  PI/I  procedures,  consists  of  the  following  (see  Figure 
2.3)  : 

a.  Control:  This  module  contains  the  main  menu  where 
the  user  will  be  able  to  choose  how  he  will  utilize  the 
Signal   Processor   Model. 

b.  Create:  This  module  allows  the  user  to  interac- 
tively construct  the  initial  environment  of  targets  and 
hew  they  will  change  throughout  the  time  of  the  simula- 
tion. 

c.  Delete:  This  module  allows  the  user  to  delete 
targets  from  the  environment  at  any  desired  simulation 
time   point. 

d.  Change:  This  module  allows  the  user  to  change  the 
environment  during  the  initial  creation  of  the  environ- 
ment . 

e.  Euild_ Data  case :  This  module  is  not  called  by  the 
ccntrcl  module,  but  interfaces  between  the  database 
utilized  to  represent  the  environment  and  those  modules 
utilized  through  "control"  to  initially  create  and 
further  modify    and  run    the  simulation.      It    must   be   able 
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to  fcuild  a  set  of  output  messages  based  on  the 
previously  developed  target  data,  and  to  send  those 
messages  to  the    REMEX    for   storage. 
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Figure  2.3        Database    Design. 
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E.       THE    STATIC    MODEL 

The  design  of  the  Static  model  depends  on  the  ability  to 
read  sequentially  arranged  previously  stored  output  messages 
from  the  hard  disk.  When  keyed  by  a  dwell  command  from  the 
SPY-1A  Track  Scheduling  module,  an  output  message  will  be 
placed  in  common  memory  providing  the  SPY-1A  Radar 
Controller  system  with  feedback.  It  does  not  matter  whether 
the  output  message  offers  a  "logical"  response  to  the 
requested  dwell,  just  that  it  offers  a  response  that  will 
causa  the  SPY-1A  System  to  send  another  dwell  command.  3y 
timing  the  SPY-1A  System  as  it  runs  in  interface  with  the 
Static  Model,  the  user  will  be  able  to  acertain  the  real- 
time performance  of  the  SPY-1A  model  and  whether  cr  not  the 
concurrent  multiprocessor  system  can  indeed  operate  within 
the  specifications  of  the  AEGIS  SPI-1A  Radar  Controller 
system. 

Utilizing  the  previously  discussed  target  database 
design,  a  Target  Database  to  be  utilized  by  the  Static  Model 
can  be  created.  The  Static  Model  consists  of  functional 
modules  that  must  be  able  to  retrieve  sequential  data  from 
the  REMEX  Data  Warehouse,  and  respond  to  each  new  dwell 
command  (tabl_58)  sent  by  the  Radar  Scheduler  with  a  set  of 
one  cr  mere  feedback  messages  (tabl_8)  that  would  have 
resulted  from  a  simulated  radar  dwell.  To  enable  the  capa- 
bility tc  time  the  turnaround  speed  of  the  SPY-1A  Model,  a 
CRT  display  will  be  required  that  allows  measurements  to  be 
made.  It  is  important  that  the  display  include  only  the 
minimum  data  so  that  it  will  not  impede  the  performance  of 
the  Static  Model,  and  thereby  detract  from  the  objective  of 
measuring  the  SPY-1A  System  Model  real-time  performance. 
Figure  2.4  shows  the  Static  Model  functional  modules  in  a 
hierarchial    design.  It  is   envisioned   that      the   concurrent 

activity      of  the      SP7-1A      Radar      Controller   and      the      Signal 
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Figure    2.4        Static   Hodel   Design. 

Processor  Simulation  will  be  sequenced  using  the  MCORTEX 
Operating  System  functions  [Ref.  9]  implementing  Eventcounts 
and  Sequencers.  Thus,  although  that  interface  is  not  avai- 
lable now,  the  AWAIT  and  ADVANCE  primitives  will  be  used  at 
some  future  date  by  the  AEGIS  Modeling  Group.  In  the  mean- 
time, in  keeping  with  the  design  goal  of  changeability 
(separating  and  modularizing  those  items  likely  to  be 
changed),  the  AWAIT  and  ADVANCE  primitives  must  still  be 
incorporated  in  the  design  and  implemented  for  proper  system 
testing. 
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III.     IBPLEMENTATICN   OP   THE    SIGNAL    PROCESSOR    SIMOLATION 

A.       TARGET    HARDWARE 

The  present  experimental  computer  system  consists  of  a 
MULTIEUS  backplane  that  contains  enough  space  for  twelve 
(12)  Intel  SBC  86/1 2»s  (Single  Board  Computers)  ,  four  (4) 
ADM-3  terminals  connected  to  the  four  (4)  currently 
installed  iSBC  86/1 2A  boards  and  two  different  hard  disk 
memory  storage  devices.  (see  Figure  3.1).  The  main  storage 
device  is  the  Remex  Data  Warehouse  disk  unit  [Ref.  8]  which 
contains  two  standard  8  inch  IBM  format  floppy  disk  drives 
(one  cf  which  is  used  to  boot  the  system)  ,  and  a  four  head 
fourteen  inch  Winchester  technology  hard  disk  containing 
twenty  mega-bytes  of  store.  The  other  storage  device  is  the 
Micropolis  Hard  Disk  system  [Ref.  10]  which  has  five  heads 
and  contains  an  additional  thirtyfive  mega-bytes  of  storage 
space.  In  both  storage  systems,  the  user,  under  the  CF/M 
operating  system,  is  allowed  to  write  only  to  the  disk  that 
the  terminal  device  was  initially  logged  into,  although  full 
read  capability  across  all  fixed  storage  devices  is  allowed. 
Shared  memory  consists  of  3 2K  bytes  of  Random  Access  Memory 
(RAM)  that  has  been  assigned  the  base  address  of  OEOOO:0000 
hexadecimal.  Occupying  one  of  the  twelve  board  slots,  there 
is  also  a  r.on- vclative  bubble  memory  which  was  in  the  past 
utilized  for  the  toot  precedure  during  initialization 
[Ref.  6]  but  is  currently  utilized  as  temporary  storage  tc 
boot  the  operating  sjstem  into  each  of  the  iSBC  86/12  boards 
in    use. 

The  Intel  SBC-86/12's  use  an  8  Mhz  clock  and  contain  64k 
of  internal  memory  that  can  be  used  for  on  board  processing. 
Each    cf    the      iSBC   86/12fs   is  connected   to      an    ADM-3    terminal 
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that    is      used  for  communication.  The   operating      system   is 

Digital   Research's    CE/M-86    [Ref.    11]    as    modified   by    previous 
thesis   students    [Ref.   6]   to    enable  the   sharing  of    peripheral 
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Figure   3.1        NPS   AEGIS  Modeling  Group   Experimental  Computer. 

devices.  There  is  an  executive  called  the  "Multicomputer 
Real  Time  Executive"  (MCORTEX)  [Ref.  9]  that  has  been 
written  tc  allow  fcr  concurrent  computation  by  the  SEC's. 
It  occupies  close  to  6k  bytes  of  storage  on  each  of  the 
SBC's.  It  is  projected  that  it  will  take  aproximately  8  or 
9  SBC's  to  carry  out  the  same  processes  that  the  four  AN/UYK 
7's    presently  do   in    the   Spy-1A   Radar    Controller. 
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B.  SCFTSARE   DEVELOPMENT    ENVIRONMENT 

Recent  aguisitions  by  the  NPS  AEGIS  Modeling  Group  have 
made  the  Software  Development  Environment  available  on  the 
experimental  computer  much  tetter.  The  multicomputer  system 
operates  under  the  CF/M-86  operating  system.  In  the  past, 
programing  has  teen  done  with  Intel's  PLM-86  Compiler  and 
the  ASM-86  assembler  for  use  on  the  iSBC  86/12.  The  SPY-1A 
major  modules  have  been  written  utilizing  the  PL/I-80 
Compiler  based  on  the  Intel  8080  microcomputer.  Now,  the 
FL/I-86  Compiler  [Ref.  12]  has  been  released  and  is  avai- 
lable for  programming  use.  Because  of  the  reguirement  for 
128  k-bytes  of  RAM  for  the  use  of  the  PL/I-86  Compiler,  it 
can  only  be  utilized  by  one  of  the  four  users  at  a  time.  In 
addition,  where  in  the  past  programmers  have  gone  to  great 
lengths  to  avoid  the  use  of  the  only  available  CP/M-86  text 
editor  ED,  the  full  screen  text  editor  WORDSTAR  is  now 
available . 

C.  ADA    CESIGN    VS    PL/I-86   IMPLEMENTATION 

The  previously  discussed  design  process  utilizing  Ada 
was  insightful  and  useful  as  a  tool  for  program  development, 
but  the  iiiplementaticn  language  for  the  AEGIS  Modeling  group 
is  PL/I.  The  primary  structure  resulting  from  the  object- 
oriented  design  methodology  is  the  Ada  "package".  The 
package  in  Ada  serves  to  promote  data  abstraction  and  infor- 
mation hiding.  PL/I  does  not  offer  a  construct  similar  to 
Ada's  "package"  structure,  but  abstraction  of  the  data  mani- 
pulation and  hiding  the  form  of  the  implemented  database  can 
readily  te  achieved.  The  modules  that  are  contained  within 
zhe  Ada  packages  are  written  as  a  logical  grouping  of  proce- 
dures -  the  primary  module  structure  in  PL/I.  The  subpro- 
gram utilized  as  a  control  program  in  the  Ada  design  is 
logically      implemented  with      a      controlling   procedure,        the 
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"procedure      options       (main)  "      in      PL/I.  The      Ada      package 

containing  the  target  information  is  implemented  with  the 
global  declaration  "  CEAS  E.  DCL"  and  the  resulting  linked  list 
used    to   develop    the    Target- List.  The    Ada   database   package 

is  implemented  with  the  PL/I  array  data-structure  "BUFFER", 
which  is  hidden  within  the  "BLD_DATABASE"  procedure.  The 
"BLD_EATAEASE"  procedure  is  not  accessible  directly  to  the 
user,    and   thus    further  hides   the    form    of  the   database. 

D.       MODULES    OF    THE    TAEGET    DATABASE 

1  *      General    Comments 

A  useful  feature  in  PL/I  is  the  "%INCLU"DE"  statement 
which  allcws  one  to  make  the  compiler  include  programs  or 
declarations     that      have      been      previously      written.  This 

feature  is  most  commcnly  utilized  to  include  declarations 
that  are  used  by  more  than  procedure  throughout  a  system. 
The  "global  declarations " (DBASE. DCL)  utilized  in  the 
Target-Database  modules  are  treated  in  this  manner.  Future 
maintenance  on  the  Signal  Processor  Interface  Simulation 
that  iray  modify  the  Target-List,  can  be  made  to  DBASE. DCL, 
and  after  the  program  is  re-compiled  and  re-linked,  it  will 
appropriately  affect      all  the    pertinate    modules.  In   addi- 

tion, :wc  global  variables  within  the  functional  grouping  of 
the    Target-Database      modules   are    defined.  These    variables 

are  declared  as  "external"  initially  in  the  main  procedure 
"Control",  and  are  also  part  of  the  global  declarations 
utilized  by  the  Target-Database.  The  two  variables  are 
"delta_t"  and  "endtime",  and  should  be  noted  and  protected 
appropriately  by  any  future  changes  made  to  the  modules  of 
the  Signal  Processor  Interface  Simulation.  It  should  be 
noted  that  "delta_t"  is  not  utilized  by  either  the 
Target-Database  or  the  Static  Model,  but  has  been  included 
because      it    will      impact   on      the      future   use     of   the      Signal 
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Processor  Interface  Simulation.  It  is  meant  to  define  the 
ratio  of  how  many  dwell  commands  are  received  versus  the 
number  cf  times  the  database  buffer  in  common  memory  is 
updated.  "Delta_t"  is  meaningful  for  the  Dynamic  Mcdel  and 
will  impact  en  the  length  of  time  a  test  run  will  be  able  to 
run  (based  on  available  memory  space  for  a  database  and 
chosen  delta_t)  . 

2  .   C C N TRO L  .  PL  I 

The  Control  procedure  is  the  head  node  of  the 
hierarchial  structure  of  procedures  used  to  modularize  and 
structure  the  i  nple  irentati  on  of  the  Radar  Signal  Processor 
Interface  Simulation.  It  contains  the  Main  Menu  that  the 
user  will  be  continually  coming  back  to  to  route  himself  to 
other  functional  branches  of  the  tree-like  system.  The  Pl/I 
exception  handler  ON  <condition>  <body>  is  utilized  first 
here  and  throughout  the  other  modules  to  prevent  abrupt 
program  termination  and  promote  graceful  recovery  in  the 
event  of  user  entry  errors.  Within  the  ON-body  a  series  of 
IF-THEN  statements  are  used.  These  will  allow  one  tc  deter- 
mine in  which  interactive  block  the  error  was  committed. 
The  variable  named  "block"  is  set  to  different  integer 
values  -hrcughout  the  program  to  signal  where  the  user  is, 
and  where  is  the  appropriate  place  in  the  program  to  return 
the  control,  so  that  interaction  can  continue.  The  reader 
may  be  aghast  at  the  flagrant  and  apparently  unstructured 
use  cf  "gc  to"s  in  this  and  further  modules  within  the 
On-bcdy      exception    handlers.  One    should      be  assured      that 

exception  handlers  are  probably  the  only  generally  accep- 
table and  appropriate  time  to  use  the  "go  to"  in  a  struc- 
tured program.  EL/I  a ddditionally  offers  a  further 
exception  handling  feature,  the  SIGNAL  <condition>  command. 
When  used  in  conjuction  with  an  IF  <condition>  THEN 
<statement>     control   command,        the   signal      command   has      the 
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effect  of  "signalling"  the  system  that  the  defined  error 
(the  conditicn  of  the  signal  call)  has  occured.  The  control 
is  transfered  automatically  to  the  appropriate  ON-unit 
defined      for      that      signalled        error.  This      enables      the 

programmer  not  only  to  gracefully  react  to  defined  system 
errors,  tut  to  define  his  own  error  conditions  and  gracefuly 
continue  operations.  The  Control  module  and  the  ether 
modules  in  the  Signal  Processor  Emulation  utilize  this 
feature  tc  prevent  the  user  from  entering  a  response  outside 
the  definsd  allowable  range.  Finally,  the  REVERT  <error 
type>  statement  is  required  at  the  end  of  each  module  where 
the  ON  exception  handler  is  utilized.  A  stack  is  utilized 
in  PL/I  to  save  the  state  of  the  current  ON-conditicns  when 
calling  another  procedure.  PL/I-86  allows  sixteen  nested 
ON-units  on  the  stack.  Proper  utilization  of  the  REVERT 
command  will  pop  the  stack  appropriately  to  ensure  that  the 
proper  CN-unit  is  used.  Functionally,  the  Control  procedure 
sets  up  the  global  variable  "endtime"  that  is  utilized  by 
the  other  Target-Database  modules  (create,  delete,  change, 
printlst,  and  bld_database)  to  define  the  limits  of  time  for 
which  the  database  is  to  be  constructed  en  the  REMEX  Data 
Warehouse. 

3.       CREATE.  P LI 

The  Create  procedure  has  the  function  of  interac- 
tively contructing  a  linked~list  (the  Target-List)  of  target 
nodes  that  contains  the  data  for  the  database  of  discretely 
timed  output  messages  (tabl-8).  The  linked  list  utilizes  a 
pointer  tc  the  header  node  (appropriately  called  "head") 
that  will  be  used  by  the  other  modules  in  their  subsequent 
manipulations  of  the  Target-List.  The  other  two  pointers 
utilized  (tgt_ptr,  and  tgt_mkr)  are  used  to  traverse  the 
linked  list  and  manipulate  fields  on  nodes,  or  nodes  them- 
selves. The      PL/I        "^INCLUDE"        statement      allows        the 
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declaration  of  the  linked  list  structure  "Target"  without 
having  to  declare  it  in  every  module  it  is  referenced.  The 
Target-List  is  implemented  as  a  linked  list  to  allow  the 
roost  efficient  use  of  storage  during  the  run-time  environ- 
ment of  the  system.  FL/I  will  only  initiate  storage  for  the 
nodes  of  the  linked  list  during  run-time,  as  required  by  the 
"ALLOCATE"  command.  Thus,  instead  of  being  restricted  to  a 
particular  array  size  (had  that  data  structure  been  used)  as 
allocated  at  compile  time,  the  user  is  restricted  to  the 
available      memory   at     that      time.  In    this      version,        the 

Target-List  is  constrained  to  56  nodes  (or  targets) ,  since 
the  buffer  size  and  corresponding  sector  size  of  the  FEMEX 
Data  Warehouse  is  fixed  at  512  bytes.  After  the  user  steps 
building  the  Target-List,  the  initial  Target-Datatase  is 
constructed  with  a  call  to  the  "Bld^database"  procedure. 
Note  that  the  first  parameter  to  Bld_database  is  a  constant 
"1".  This  will  ensure  that  the  first  database  built  on  the 
REMEX    begins  at    the    first   discrete  delta_t   time   value. 

4.       DELETE.  PLI 

The  purpose  of  this  module  is  to  delete  target  nodes 
from  the  Target-List  as  requested  by  the  user.  The  user  has 
previously  interactively  indicated  the  specific  discrete 
"time_in"  value  of  the  call,  and  this  information  will  be 
further  utilized  by  the  procedure  "Bld_database"  in  its  call 
hy  Delete.  Delete  will  request  a  target  node  number  of  the 
node  to  re  deleted  from  the  Target-List.  Then,  the  pointers 
tgt_ptr  an(^  tgt_mkr  are  utilized  to  traverse  the  linked  list 
until  the  appropriate  target  node  has  been  located.  When 
found,  the  target  node  is  separated  from  the  Target-List, 
and  placed  back  in  available  free  memory  store  by  the  use  of 
the    PL/I      "FREE"   command.  If  the   target      node    can      net   be 

found  (indicated  by  the  pointer  tgt_ptr  reaching  the  "null" 
node) ,      the     user   will     receive   an     error   statement      and   the 
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While  lccp  controlling  this  process  will  return  the  user  to 
ask  if  there  is  another  node  to  be  deleted.  When  the  user 
has  deleted  all  the  targets  he  desires,  the  call  will  be 
made  to  the  MBld_database"  procedure  to  re-build  the  data- 
base from  the  previously  defined  delxa_t  discrete  time 
increment  ("time_in")  to  the  previously  defined  "endtime". 
Control  will  then  return  to  the  Main  Menu  (the  Control 
procedure) . 

5.  CHANGE. P LI 

The  Change  procedure  is  similar  to  the  Create  proce- 
dure since  it  allows  the  user  to  re-define  the  fields  of  any 
given  node  on  the  linked  list  Target-List  in  an  interactive 
mode.  Once  again,  in  a  manner  similar  to  the  Delete  proce- 
dure, the  user  will  define  the  discrete  delta_t  time  value 
where  the  Target-List  is  to  be  changed,  prior  to  the  call  to 
Change.  This      value      "time_in"      will      be      passed      to      the 

"Bld_datacase"  procedure  in  the  same  manner  as  with  Delete 
for  further  Target-Database  re-construction.  The  Change 
procedure  allows  the  user  to  not  only  change  the  parameters 
used  by  the  defined  parametric  equation  but  to  change  the 
equation  (and  therefor  the  shape  of  the  resultant  track) 
i-self.  The  user  is  placed  in  a  While  loop  to  change  all 
the  targets  he  desires  on  the  Target-List,  until  he  indi- 
cates he  is  finished.  At  that  time  the  procedure 
"Bld_datatase"  is  called  to  re-build  the  Target-Database  en 
the  FEMEX  Data  Warehouse  from  the  time  given  in  the  first 
parameter  "time_in"  to  the  "endtime",  both  previously  deter- 
mined  by   the  user. 

6.  BIDDATABASE.PLI 

This  module  is  the  real  workhorse  of  the 
Target-Datatase      building      system.  The        purpose      of      the 

Bid    database  module    is  to  convert     the   data   contained   on   the 
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Target-List  to  an  Array  of  output  massages  to  be  placed  in  a 
based  structure  called  "Buffer",  and  then  to  transfer  that 
Buffer  tc  another  buffer  of  egual  size  in  the  NPS  axperi- 
mental  computer's  common  memory.  At  that  timer  the  appro- 
priate message  will  be  sent  to  the  REMEX  Data  Warehouse 
commanding  it  to  read  the  data  (using  Direct  Memory  Access  - 
DMA)  onto  the  required  track  and  sector  of  the  REMEX  hard 
disk.  To  accomplish  these  tasks,  Bld_database  utilizes 
three  assembly  language  routines:  Bld_buff,  Euild_cmd_mess, 
and  Send_mess.  Bld_fcuff  utilizes  the  pointer  to  the  struc- 
ture "Buffer"  and  causes  the  structure  to  be  copied  into 
common  memory  starting        at  location  0E000:5500. 

Build_cmd_mess  uses  8  parameters  to  build  an  appropriate 
REMEX  command  message  formated  for  a  "read"  operation  into 
common  memory  starting  at  location  QE000:5400.  Send_mess 
tells  the  REMEX  it  has  a  command  message  at  location 
0E000:5400  and  verifies  that  the  REMEX  has  received  and 
responded  tc  the  message.  Bld_database  utilizes  these  three 
primitive  routines  within  two  sub-procedures 

"bld_msg_buf fer"  and  "call_rdw".  The  subprocedures  them- 
selves are  called  sequentially  from  within  the  execution  of 
a  PL/I  DC  loop  that  runs  from  the  Bld_database  parameter 
"time_in"  to  the  global  variable  "endtime".  The  astute 
reader  iray  now  see  why  the  user  needs  to  build  his 
Target-Database  in  a  sequential  manner,  making  deletions  and 
changes  in  a  progressively  increasing  discrete  time  incre- 
ment up  to  "endtime".  If  modifications  are  not  done  in 
discrete  sequential  time,  Bld_database  will  write  over  the 
changes  that  had  been  already  written  to  the  database  with  a 
higher  value  time  increment  than  the  current  "time_in" 
defined.  The  sub_procedur e  bld_msg_buf f er  will  utilize  the 
Target-List  to  build  a  corresponding  output  (tabl_8)  message 
to  be  incrementally  placed  in  the  Buffer  structure  sequen- 
tially  as   the   linked    list  is   traversed.      Reaching   the   "null" 
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node  will  cause  the  while  loop  to  end,  and  a  call  tc  the 
bld_buff  primitive  routine  to  be  made.  The  x,  yr  and  z 
named  fields  for  each  component  of  the  Buffer  array  will  be 
constructed  by  the  parametric  equation  number  indicated  in 
the    Target-List.  These  parametric    equations      were   derived 

from  a  previous  thesis  work  done  by  Boone  [Ref.  3]  and  are 
utilized  here  tc  maintain  overall  SPY-1A  system  compati- 
bility  and    integrity.        See    Figure   3.2      for   a   listing   of   the 


(1)      x  (t)    =   a    +   t*t   +    c*t*t 

y  (t)    =   u    ♦   v*t    +    w*t*t 


z  (tj     =   d 

(2)      x  (t)     =  a    +    b*t   +    c*t*t 
y  (t)     ■   u    ♦    v*sin  (w*t) 


z  (t)     =   d 

(3)  x  (t)     =   a  +  b*cos(c*t) 

y  (t)     =  u  +  v*t   +    w*t*t 
Mt]     =    d 

(4)  x  (t)     =   a  +  fc*cos  (c*t) 
u  +  v*sin  ( w*t) 


z   t      =   d 


Figure    3.2        Signal   Processor   Track    Parametric   Equations. 

parametric  equations.  These  parametric  equations  can  easily 
be  changed  if  desired  by  future  users  of  this  system,  if 
specific  requirements  so  dictate  it.  The  sub- procedure 
load_rdw  uses  the  primitives  build_cmd_mess  and  snd_mess  to 
cause  the  EEMEX  to  read  the  data  from  the  common  memory 
buffer.  Twc  of  the  parameters  to  the  routine  Build_cmd_mess 
require  the  track  and  sector  to  be  designated  where  the 
REMEX  will  subsequently  store  the  common  memory  buffer.  To 
ensure  that  the  track  and  sector  are  located  in  a  sequential 
and   therefore     easily   retrievable   manner,        a   set      of   simple 
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algorithns  were  devised.  The  algorithms  will  require  buffers 
to  be  stored  starting  at  a  location  indicated  by  "time_in" 
and  sequentially  building  each  of  39  sectors  per  hard  disk 
track  until  "endtime"  is  reached  or  the  memory  is  depleted 
(at    track   210).      The    algorithms   are: 

sect   ~    1    +  mod ( time_in,40) 

track  =  1  +  trunc  (time_in/39) 
The  "sect"  algorithm  will  convert  time_in  to  a  modulo  40 
number  (0-39)  and  add  1  (since  the  sectors  are  number  1  to 
39  per  track).  The  "track"  algorithm  will  divide  time_in  by 
39  and  truncate  the  resultant  number  to  get  an  integer.  It 
then  adds  1  (since  the  REMEX  does  not  allow  the  use  of  track 
0  to      the   user) .  The  subsequent      calls   are      then    made      to 

build_cmd_mess  a  r.d  snd_mess  in  that  order.  Upon  completion, 
Bld_database  returns  to  the  procedure  from  where  it  was 
called  (Create,  Delete,  and  Change)  and  then  to  Control  to 
the    Main    Menu  once   again. 

7.      I BINTLST.PL I 

The  Print_lst  procedure  is  meant  to  be  a  tool  for 
the  user  to  maintain  a  listing  of  the  Target_List  as  the 
list  is  initially  created  and  as  changes  are  made  during  a 
database  building  session.  The  procedure  will  prompt  the 
user  to  turn  on  the  printer  or  hit  <control>  "P"  to  activate 
the  printer,  before  typing  "0"  to  begin  a  print  of  the 
Target_List  .  The  Target-List  print  out  will  be  initialized 
with  a  record  of  the  time  in  ("time_in")  for  proper  record 
keeping,  and  the  linked  list  will  be  traversed,  reading  and 
printing  the  fields  contained  on  each  node.  When  the  "null" 
node  is  reached,  the  procedure  returns  control  to  the 
Control   procedure   Main  Menu. 
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E.        HODOLES    OF    THE    STATIC   MODEL 

1  ■      General   Comments 

The  purpose  of  Static  Model  is  to  run  through  the  developed 
Target-Database  in  as  rapid  a  manner  as  possible,  reponding 
to  eventccunts  from  the  SPY-1A  Model  (indicating  a  dwell 
command  has  been  sent)  by  transfering  a  output  message  to 
common  memory.  The  SPY-1A  is  then  further  notified  that  a 
message  is  ready  fcr  it1 s  input  by  the  advancing  of  a 
corresponding  eventccunt.  The  display  of  the  Static  Model 
is  merely  a  counter  indicating  each  data  transfer  made  (set 
of  output  messages)  from  the  REMEX  Target-Database  tc  common 
memory,  and  the  anticipated  endtime  (or  endpoint)  for  the 
Static   Model  simulation   run. 

2.      STATIC.PLI 

The    Static   procedure      is   the    main    procedure      for   the 
running   of   the    Static  Model.  The   procedure   can    operate   in 

one  cf  two  possible  modes.  The  first  mode  is  an  actual  run 
of  the  NFS  SPY-1A  Model  as  it  will  be  eventually  interfaced 
for  testing.  It  is  assumed  that  the  MCORTEX  operating 
system  will  be  utilized  to  enable  proper  interaction  between 
concurrent  processes,  therefor  eventcounts  and  sequencer 
primitives  are  used  in  the  calls  herein  (which  will  be 
replaced  by  appropriate  calls  to  that  operating  system  at 
some  future  time).  In  the  meantime,  to  allow  testing  of  the 
Static  Model,  an  AWAIT  primitive  was  written,  and  an  ADVANCE 
primitive   is     utilized  in      the   test      program    SPYTEST.  The 

Static  Model  will  loop  through  the  Target  database  in  a  PL/I 
DO  loop  from  discrete  time  1  to  endtime.  Within  the  loop, 
sequential       calls        are      made        to        AWAIT,  Load_buff er, 

Send_cutput,  and  Display.  when  the  user  begines  a  test-run 
with  the  SPY-1A  Simulator,  he  will  be  prompted  to  load  that 
program      en    another      iSBC      86/12      console,      and      then      begin 
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operating.  At  that  point,  the  same  loop  will  be  run  as 
previously  described.  The  user  may  also  leave  the  Static 
Model    and    return   to    Control •s    Main   Menu. 

3.  I CAEJ3UFF.PL  I 

The  purpose  of  this  module  is  to  extract  the  proper 
sector/track        combination        of        data  from        the        REMEX 

Target-Datafcase,  and  place  it  in  the  common  memory  buffer. 
It  is  the  same  as  the  Bld_Buffer  sub-procedure  previously 
described  as  a  part  of  Bld_database,  except  the  parameters 
to  the  primitive  routine  Build_cmd_mess  are  to  "write" 
instead   of   read. 

4 .  XJER . A8 6 

The  purpose  of  this  module  is  to  transfer  a  output 
message  (tabl_8)  from  the  common  memory  buffer  to  common 
memory   location    starting   at    0E00O:6O55. 

5.  ADV1EVC. A86 

The  purpose  of  this  module  is  to  advance  an  event- 
count  in  common  memory  to  notify  SPYTEST.PLI  that  the  output 
message    is   ready  to    re  read. 

6.  CISFLAY.PL  I 

The  purpose  of  this  procedure  is  to  send  to  the 
terminal  screen  the  "time"  corresponding  to  the  seguential 
transfer  of  sectors  of  data  from  the  REMEX  Data  Warehouse, 
and  show  the  user  the  expected  endtime  for  that  particular 
run.  This  should  enable  the  user  to  determine  the  "real- 
time"   capability  of    the   SPY-1A   Model. 
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F.  ASSEMBLY,  COMPILING,  AND  LINKING 

The  assembly  language  code  was  written  in  ASM-86  and 
assembled  using  RASK-86.  This  assembler  produces  reloca- 
table files  that  can  then  be  linked  with  compiled  PL/I -86 
files.  The  PL/I-86  Compile r  was  utilized  for  compilation  of 
the  PL/I  programs,  and  the  resulting  assembler  and  compiler 
".OBJ"  files  were  tten  linked  using  LINK86 .  The  LINK86 
linker  enables  the  user  to  develop  a  ".INP"  file  containing 
the  list  cf  program  commands  the  user  would  normally  have  to 
type  in,  and  the  linker  can  then  be  optionally  utilized  with 
the  command  "LINK86  <file  name>.INP  [ INPUT  ]".  This  greatly 
speeds  the  link  process  and  assists  during  run-time  testing 
and    debugging.       See    [Ref.    12]   for   further    information. 

G.  TESTING 

Most  cf  the  implementation  of  the  PL/I  code  was  done 
using      PL/I-80    instead      of      PL/I-86.  This   was      convenient 

because  of  the  extensive  availability  of  microcomputers 
using  PL/I-80  versus  PL/I-86.  Most  of  the  early  testing  was 
done  via  extensive  cede  reading  and  revision.  As  a  result, 
during  top-down  testing  of  modules,  (utilizing  program  stubs 
for  the  assembly  language  subroutines) ,  the  system  worked 
with  few  runtime  errors.  Initially,  the  linked  system  did 
not  contain  the  PRIN1LST.PLI  code  it  now  incorporates.  This 
code  was  developed  as  a  test  routine  to  insure  that  the 
Target-List  and  the  Euffer  data  structures  were  being  built 
in  the  proper  manner  and  receiving  the  proper  data.  However 
the  program  was  perceived  as  a  desirable  tool  for  recording 
target  data  while  developing  a  Target-Database  in  the  Signal 
Processor  Interface  Simulation,  and  was  therefore  incorpo- 
rated into  the  system.  The  top-down  testing  philosophy 
enabled  testing  to  be  implemented  in  PL/I-80.  This  provided 
programming   and      testing    flexibility      when   the      experimental 
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computer  became  a  contended  resource  by  AEGIS  group  members. 
The  use  cf  DDT-86  (Dynamic  Debugging  Tool)  to  check  memory 
locations  and  incrementally  run  the  system  proved  tc  be  the 
most  important  tool  for  testing  and  verifying  the  Signal 
Processor  Interface  Simulation  when  the  assembly  language 
routines  were  linked  and  the  experimental  computer  was 
utilized. 
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IV.    CONC LOS IONS 

A.       UTILIZATION      AND    CHANGABILITY      OF       THE    SIGNAL       PROCESSOR 
SIMULATION 

The  Signal  Processor  Interface  Simulation  is  a  tcol  that 
can  be  cf  significant  value  to  future  testing  of  the  NPS 
AEGIS      Group's       AN/SPY-1A      Radar        Controller      Model.  The 

Target-Database  system  was  developed  to  allow  it's  use  not 
only  with  the  Static  Model  as  specifically  implemented  in 
this  version,  but  also  as  the  basis  for  a  version  to  inter- 
face with  a  Dynamic  Model.  The  individual  functions  that 
make  up  the  total  Signal  Processor  Simulation  Sytsm  have 
been  modularized  to  enhance  the  use  and  adaptability  of  this 
versicn  to  what  ever  future  directions  the  Simulation 
efforts  cf  the  AEGIS  Modeling  Group  may  be.  A  comprehensive 
Users  Manual  has  been  provided  in  Appendix  F  for  use  with 
this  version  of  the  Signal  Processor  Simulation  as  a  stand 
alone  document.  The  only  interfacing  required  for  the 
members  cf  the  AEGIS  Modeling  Group  with  regards  to  this 
Signal  Processor  Simulation  should  be  the  substitution  of 
MCORTEX  "await"  and  "advance"  primitives  for  those  utilized 
in  this  version  of  the  Static  Model,  and  the  possible 
restructuring  of  the  address  locations  in  common  memory.  It 
is  recommended  that  any  tester  of  the  NPS  SPY-1A  Radar 
Controller  Model  first  gain  experience  of  the  Signal 
Processor  Simulation  by  running  the  Simulated  SPY-1A  Program 
"SPYTZST.CMD". 
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B.       FUTURE    ENHANCEMENTS    AND    DIRECTION    FOR    THE    SPY-1A    MODEL 

The  next  logical  step  in  the  full  implementation  of  the 
Signal  Processor  Interface  Simulation  is  the  further  design 
and  implementation  of  the  Dynamic  Model.  The  purpose  of  the 
Dynamic  Model  is  to  test  the  logic  of  the  NPS  SPY-1A  Padar 
Controller  Model.  The  Dynamic  Model  does  not  require  the 
real-time  performance  of  the  Static  Model,  but  must  provide 
a  comprehensive  display  of  the  active  targets  representing 
the  Target-Database  at  each  discrete  time  increment.  The 
Target-Database  system  developed  in  this  thesis  should 
provide  the  basis  for  changing  the  structure  of  the 
Target-Database  as  the  limits  of  the  logical  functions  of 
the  system  are  explored.  However,  the  Target-Database  has 
been  purposefully  designed  for  change  should  that  be  neces- 
sary in  the  implementation  of  the  Dynamic  Model.  Previous 
thesis  work  by  Boone  [Ref.  3]  should  assist  in  the  develop- 
ment of  the  Display  module  required  for  the  Dynamic  Model. 
Finally,  the  messages  utilized  (tables  58  and  8)  for  input 
and  output  from  the  Signal  Processor  Interface  Simulation 
will      require  some      attention.  Specifically,      the      output 

message  (table  8)  needs  to  have  some  data  from  the  input 
message  tc  allow  the  SPY-1A  Radar  Controller  Model  to  prop- 
erly recognize  and  match  input  dwell  commands  with  output 
data . 
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APPENDIX    A 
TARGET    DATABASE    PROGRAH    LISTINGS 


A-       CONTROL. PLI 

Frog    Name      :    CONTROL. ELI 

Date  :   May   83 

Written   by    :   Toad  B.    Kersh 

For  :   Thesis     (AEGIS    Modeling  Group) 

Adviser  :   Professor  Kodres 

Purpose  :   This   is   the   main    program   -co    control    the 

operation   of  the   Signal   Processor   Simulation   Target 

Database    functions    and  the    Static  Model    functions. 

*/ 

contrcl:procedure  options    (main); 

declare 

create  entry  (pcint  er)  c 
delete  entry  (fixed  ,Domter)  , 
change  entry  (fixed, po  inter)  , 
printlst    entry  (pointe  r,  fixed)  , 
static  entry; 

declare 

block    fixed   binary  (7)  , 

init    fixed  decimal  (2 ,  1)  , 

initl  fixed, 

choice  fixed  binary(7), 

delta  t  fixed  decimal  (2,1)  EXTERNAL, 

andtime  fixed  decimal  (H,  1)  EXTERNAL, 

tine  in  fixed, 

head  pointer; 

entry  errors  */ 

on  error  (1) 
beain ; 

if    block  =    1  then    do; 

put    list  (ascii  (26)  ,ascii  (30)  )  ; 
put    skio    list (' invalid  entry,    try   again...'); 
oo    to   start; 
end; 
if    block   =    2   then    do; 

out    list  (ascii ( 26)  , ascii (30) ) ; 
put    skip   list (' invalid  entry, 

must    be    integer    1-6...  ')  ; 
go    to   menu; 
end  ; 
if    block  =    3  then    do; 

put    list  (ascii  (  26)  , ascii  (30)  )  ; 
pur    skip    list  (•  invalid  entry, 

must    be   1-  ',  en  dtime,  '...')  ; 
go    t c   branch; 
end ; 
end; 

out   list  (ascii(26)  .ascii  (30))  ;      /*clear   screen    */ 
put    skip    list  T        '*******    SIGNAL    PROCESSOR    SIMULATION 

put    skip   list  (•  version    1.0   Jane    1983')  ; 
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pat  skip  (2)  ; 

start: 

/*   First    determine  what    the   time   interval   for   display 
updates   and    corresponding    updates    from   the   database    will 
be,    as   well    as  the  length  of   the   simulation  */ 

b lock  -    1  • 

put  skip  list  ('SYSTEM  INITIATION:  (see  users  manual)'); 

put  skip  list  ('How  often  do  you  want  the  database  and 

the  display  updated?*)  ; 
put  skip  list  (•    (delta  t  range  .  1  to  1  seconds)'); 


put  skip  list  ('    (default  is  every  .5  sec)'): 

put  skip  list  ('enter  value  or  0  for  default:  '); 

get   list  (init)  * 

if    (  (init>1 )  |  (init<.  1) )     then   signal  error  ( 1)  ; 

else    delta  t    =  init; 

put    skip    list  ('How   many    seconds  do    you   want   the 

simulation    to   run?'); 
put   skip   list  (•  (endtime   range    1 

to     (delta   t    *    8190) ) • ) ; 
put   skio   list  ('  (default    is    300    sec)')T 

put   skip    list  ('enter    value   or    0  for   default:    ')  ; 
get    list  (init  t)  ; 

if    (<init1>8190(  |  JinitKI))    then   signal   error(1); 
else    endtime    =  init1; 

/*      Next    the    user   will   be   placed   in    a   interactive 
environment    where    he   can    build   track    databases, 
run   simulation   tests,    and   change   the   track   database 
as    hs    desires   */ 

do  while  («1 ' b) ; 

put  list  (ascii  (26)  ,ascii  (30) )  ;/*  clear  screen  */ 

menu : 

blcck  =  2 • 

put  Skip  iist(«  ***  MAIN  MENU  ***•); 

put  s  k  ip  ( 2 )  ; 

put  skip  list  ('what  course  of  action  do  you  wish?')  ; 

put  skip  list?'    (1)   CREATE  a  database  of  tracks'); 

put  skip  list  ( *        (you  must  do  this  first)'); 

put   skip    list 

f}  (2)         DELETE   a   track    from   the    database'); 

cut   skip    list 

*  ('  (3)         CHANGE    a   track    on   the    database'); 

put   skip    list 

('  (4)  PRINT   the    current   target    list'); 

put  sUp  n\; 

put    skip    list 

('After  a   database    is   satisfactory    you    may: ')  ; 
put   skip    list('         (5)       RON   a  simulation'); 
put   skip    list 

(insure    the   rest    of   the   SPY-1    Model   is    setup)'); 
put   skip    list 

*('  (5)       QOIT  and   return   to    the    operating    system'); 

put   skip    list  ('(enter    1-6   and   <cr>):'); 
get    list  (choice)  ; 
if    ( (choice<1)  |  (choice>6) )    then    signal   error(1); 

branch: 

blcck   =   3 • 

if   choice*  =    1    then   call   create  (head)  ; 

if   choice    =   2    then   do; 

put  skip  list 

(•At   what    time   do    you    want    to    delete   a    target?    •); 

get   list(tijoe  in)  ; 

if    ((time_in<7)  |  (t  ime_in>endtime)  ) 
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then  signal  errcr(1)  ; 
call  delete  (time  in, head) ; 

end; 

if   chcice    =  3    then   do; 

put  skiD  list 

(•At   what    time   do    you   want   to   change   a   taraet?    '); 

get  list  (time  in)  : 

if    ((time    inCT)  |  (time   in>endtime)  ) 

then  signal  errcr(1); 

call  change  (time_in,  head)  ; 
end ; 

if  choice  =  4  then  call  printlst (head, t ime_in) ; 
if  chcice  =  5  then  call  static; 
if  chcice  =  6  then  do; 

put  skip(2)     list 


revert    err 
step; 
en  d  * 
end;    /*    while   */ 


(•  ***    END    OF    SIMULATION    ***•); 

or(1)  ; 
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E.       CREATE. PLI 


end    ccntrcl; 


Prog    Name 

Dane 

Written   by 

For 

Adviser 

Purpose 


CREATE. Ell 

May   83 

Todd  B.    Kersh 

Thesis     (AEGIS    Modeling   Grouo) 

Professor  Kodres 

This   module   is    part   of  the    Target 
Database    package  of    functions. 
*/ 


create:    procedure    (head)  ; 
/*   Global  declarations  */ 
^include    •dbase.dcl1; 
/*   Local    declarations   */ 

declare 

bid    database    entry    (fixed,  pointer)  f 

i    fixed  binary  (7) , 

cent    character(l)    static   init('Y')  , 

block    fixed   binary  (7)  , 

tgt nun  fixed   binary(7)    static   init  (0)    external, 

xrange  float, 

yrange  float, 

xvel    float, 

yvel   float. 

xacel    float, 

yacel    float, 

alt    float, 

tgteg    fixed  binary  (7)  ; 

entry   errrcrs  */ 

on    error  (1) 
begin ; 

put    skip   list  ('ENTRY    ERROR,     TRY    AGAIN...'); 
if    block  =    1    then 

go   to  retry; 
if   block  =    2   then 
go   to  again; 
end; 

put    skip    list('=  =  =    CREATE    TARGETS    MODULE    ==='); 

/*    Initiate    the    target   list   */ 

allocate    target  set  (t  gt_mkr)  ; 

tgt   ptr  =    tgt    irkr; 

heacl    =  tgt_mkr; 

tgt   ptr->num    =    0;      /*    this    is    the    header   node    */ 

allocate    target   set  (t  gt_mkr)  ; 

tgt   ptr->next_ptr   =  tgt_mkr; 

tgt'ptr  =    tgt_nkr; 

/*   Create  the   list  of   targets    to    be   simulated   */ 

do    while    (  cont    =    ■!■ )  ; 
tgtnum  =    tgtnum  +    1; 
tgt   ptr->num    =    tgtnum; 
retry: 
block   =    1 : 
put   skip    list  ( 'Initiate   target*  ',  tgtnum)  ; 

/*   Assign    the    target    parameters   */ 
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put  skip  list 

('    Parametric  Equations?  (1,2,3,crU):  '); 
get  list  (tgteq)  ; 
if  ( (tgteg<1)  |  (tgteq>4) )  then  signal  error  (1); 

put  skip  list(»    X  range  (a)?  (-256  ,  +  256)  nra:  «); 

get   list  (xrange)  ;      ~ 

if    ( (xrange<-256)  |  (xrange>256)  )    then   signal   error(1); 

put   skip    list(«        Y   range    (u)  ?     (-256  ,  +  256)  nm:     •)  ; 

get    list  (yrange)  ; 

if    ( (yrange<-256)  |  (yr ange>256) )    then   signal   error  (1); 

put    skip    list (  ■        X_velocity    (b)?     (-32, +32) m/sec:    '); 

get  list (xvel) ; 

if  ( (xvel<-32)  j  (xvel>32)  )  then  signal  error  ( 1)  ; 

put  skip  list(»    Y  velocity  (v) ?  (-32, +32) m/sec:  •); 

get   list  (yvel)  ; 

if    ( (yvel<-32)  |(yvel>32)  )    Then    signal   error  (1); 

ut   skip    list 

_acceleration    (c)  ?    (-. 0 15625,+. 0 156 25) m/sec/sec:    '); 
get   list  (xacel)  ; 
if    ((xaceK-.  0  15625)  |  (xacel>.  0  1  5625)  ) 

then   signal   error  (1); 

put   skip    list 
(f         Y_acceleration    (w)  ?    (-. 0 15625, +. 015625) m/sec/sec:    «); 
get   list  (yacel)  : 
if     ((yacelO.  015625)  |  (yacel>.  0  1  5625)  ) 

then   signal    error  (1); 

DUt   skip    list('        Z   altitude    (d)  ?     (0,20,000)  ft:     •); 

get    list  (alt)  ; 

if    ( (alt<0)  j  (alt>20000)  )    then   signal   error(1); 

tgt    ptr->eq  =    tgteq; 

tgt~pi:r->a  =  xrange; 

tgt   pxr->b  =  xvel: 

tgt~ptr->c  =  xacel; 

tgt"ptr->d  =  alt; 

tgt~p-r->u  =  yrange; 

tgt   ptr->v  =  yvel; 

tgt~ptr-> w  =  yacel; 

/*   Determine    if  more    targets  are  to    be   created   */ 

again : 

block   =   2: 

put   skip (2)    list('create   more   targets?(Y  or    N) :    '); 

get  list  (cont)  : 

if  cent  =  'y'  then  cont  =  *  Y'; 

if    ((cent    =    •  Y')&(tgtnum°=56)  )     then    do; 

allocate   taraet    set  (tgt;    mkr)  ; 

tgt_ptr->next  ptr    =   tgt^mkr; 

tgt_ptr   =   tgfmkr; 

end;  "" 

if    tgtnum    =   56    then   do; 

put   skit    list('TARGET    LIST    IS    FULL...')*, 

cont   =     *N» ; 

end; 
end;    /*while    cont    */ 
cent    =    »Y*; 

/*   Complete   the    linked   list    */ 

tgt_ptr->next_ptr   =  null; 
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-gt-Pt-    =  head; 
tgt_ihkr   =  head; 

/*    Build   the    Remex  Data    Warehouse    database.    */ 

put    skip    list  ('BUILDING    DATABASE •); 

call   1 13   database  (1, head)  ; 
revert   error  ( 1)  ; 

end   create; 
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C.       DELETE. ELI 


Frog    Name 

Date 

Written    by 

For 

Advisor 

Purpose 


DELETE.  ELI 

May   83 

Todd   B.    Kersh 

Thesis     (AEGIS    Modeling   Group) 

Professor  Kodres 

This   module   is    part   of   the    Target 


Database    package  of    functions.    It   deletes   targets 

from    the   target    List. 

V 

delete:  procedure  (time  in,  head); 
^replace 

true  by  ' 1 fb, 
false  ty  «  O'd; 

/*  Glcbal  declarations  */ 

^Include  •dbase.dcl*; 

/*   Local    declarations   */ 

declare 

bid   database   entry    (fixed, pointer)  , 

found    bit  p)    static  init  (false)  , 

tiie   in   fixed. 

tgtnum  fixed    binary(7)    external, 

tgt   fixed    binary  (7). 

cent   character  (1)    static   init('Y'); 

/*   This    exception   handler   will  take  care  of 
all   user    input  errcrs   */ 

on  error  (1) 
begin; 

put   skip    list(«ENTBY    ERROR,     TRY    AGAIN    ...')      ; 
gc   to    retry; 
end  : 
tgt   =   0; 

put    skip    list('===    DELETE    TARGETS    MODULE    ==='); 

/*   This    will    initialize    the   Target    linked   list    to   the 
correct    memory  space   */ 

tgt   ptr   =  head->next_ptr ; 
tgt^mkr    =  head; 

/*   This    will    delete  the    desired  node    from   the 
target    linked   list  */ 

do    while  (  cont   =    'Y«)  ; 

retry: 

put   skip    list 

,(»         what  target    do    you    wish    to    delete?    ')» 
put   skip    list 

(•  (tgt.    num.    range    1 -',  tgtnum,  •)  :    •); 


um)  )    then    signal   error  (1); 


get    list  (tgt)  : 

if    ((tgt<1)  |  (tgt>tgtn 

do    while  (found    =  false): 
if   tgt   ptr->num  =    tgt   then   do; 

tgt   mkr->next_ptr    =   tgt   ptr->next_ptr ; 
tgt~ptr->next  ptr    =   null; 
free  tgt   ptr-^target ; 
tgt  ptr  =    head->next_ptr ; 
tgt  mkr  =    head; 
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found    =   true; 
end; 
else   do; 

tgt  mxr   =    tgt  ptr; 
tgt~ptr  =    tgt~mkr->next   ptr; 
if  Tfgt    ptr    =  null    then  lo; 
put~skip   list 

('ERROR    :    target    number   not    found'); 
tgt    ptr    =  head->next_ptr ; 
tgt_mkr    =  head; 
found  =    true; 
end; 
end; 
end;    /*  while    */ 
found   =  false; 


put   skip    list  ('con* 
get    list  (cent)  ; 
if    cont  =    'y'    then 


put   skip    list  ( 'continue    (Y/N)  ?    '); 
nt)  ; 
y '    then    cont    =    •  Y'  ; 


and;    /*while*/ 
cont    =    'Y'; 

put    sVip(2)     list  ('EUILDING    NEW    DATABASE...'); 
call    fcla_database  (time   in, head)  ; 
revert   error  (1)  ; 

end    delete; 


52 


D.       CHANGE. ELI 


Frog    Name 

Date 

Written    by 

For 

Adviser 

Purpose 


CHANGE.  EII 

Hay   83 

Todd  B.    Kersh 

Thesis     (AEGIS    Modeling   Group) 

Professor  Kodres 

This   module   is    part   of   the   Target- 
Database    package  of    functions.    It   changes   data 
on    the   Target  List. 
*/ 


change:    procedure    (time_in,  head)  ; 

^replace 

true  by  ■ 1 «b, 
false  by  'O'b; 

/*  Global  Declarations  */ 

%include  'dbase.dcl'; 

/*   Local    Declarations   */ 

declare 

bid   database    entry    (fixed,  point  er)  , 
time_in   fixed, 

more   bit,(1)    static   init(true), 
tgtnua  fixed    binary(7)    external, 
tgt    fixed    binary  (7)  f 
(chg1,chg2)    fixed   binary  (7). 
(cfcg3fchg4  ,chg5,chg6f  chq7,chg8  ,chg9) 
do1    bit(1)    static   mit  (false), 
block    fixed  bir.ary(7)  . 
cont   character  (1)    static  initCY'); 


float. 


/*  This  exception  handler  will  take  care  of  all 
user  input  errors  */ 

on  error  (1) 
begin; 

cut   skip    lisT('ENTRY    ERROR,     TRY    AGAIN '); 

if   block  =    1   then 


go    to  tryl: 
if    block  =    <i  then 


end ; 


go    to  try2; 


put    skip    list  (•=  =  =    CHANGE    TARGETS    MODULE    ===•)  ; 

/*   First,   query   the  user    about   the   changes   to    be   made   */ 

do    while  (cont    =    •  ¥')  ; 
tryl : 

blcck   =   1: 
Dut   skip    list 

('         What    is    the  target    number    you   wish  to    change?*); 
put   skip    list 

(•  (tgt.    num.    range    1  -• , tgtnum,  •)  :    '); 

get   list  (tgt)  : 
if    ( (tgt<1)  |  (tgt>tgtnum)  )    then    signal   error  (1); 

put   skip    list.('         What    data    item   is    to    be   changed?'); 

put   skip    list?'  (1)    parametric   equation'); 

put    skip    listf'  (2)    equation    parameters'); 

get   skip    list(chgl): 

if    ( (chg1<1)  |  (chg1>2)  )    then   signal   error(1); 
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if   chgl   =    1    then  do; 

do  1  =    true; 

put  skip  list 

l\        What  is  the   new   equation    number    (1-4)  ?•)  ; 

get   list(chg2)  ;  ' 

if    ((chg2<lf|  (chg2>4)  )    then    signal   error  ( 1)  ; 
end ; 
else    do; 

try2: 

block    ■   2; 

do1  =    false ; 

put  skip  list  (•         What   are   the   new   parameters:1)  ; 
put  skip  list 

t-     ,,    S\.  X_range    (a)?     (-256  ,  +  256)  nm:     ')  ; 

get   list(chg3)  ; 
if    ((chg3<-256)  |  (chg3>256)  )     then    signal   errcr(1); 

put  skip  list 

,  .  ',  .(■      Y_range  (u)  ?  (-256  ,  +  256)  nm:  •)  ; 
get  list  (chgU)  ; 
if  ((chg4<-256)  |  (chg4>256)  )  then  signal  error  (1); 

put  skip  list 

(*  X_velocity    (b)  ?    (-32, +  32)  m/sec:     ')  ; 

get  list  (chg5)  ;~ 
if    ((chg5<- 22)  |  (chg5>32)  )    then    signal  error  (1 )  ; 

put  skic  list 

('  Y   velocity    (v)  ?     (-32,  +  32)  m/sec:     ')  ; 

get  list(chg6)  :" 
if    ((chg6<-32)  |  (chg6>32)  )    then   signal  err cr  (1)  ; 

put  skip  list 

X  accel.   ic)  ?  (-.015625, +  .015625)  m/sec/sec:  •); 
get  list  (ch  g/)  ; 
if  ((chg7<-:015625)  |  (chg7>.  0  156  24) ) 

then  signal  error  (1); 

put  skip   list 

Y_accel.       jw) ?    (-.015625, +.015625) m/sec/sec:    '); 
get   list  (chgS)  • 
if    ((chg8<-.01§625)  |  (chg8>.  0  15625) ) 

then   signal   error  (1); 

put  skip   list(«  Z   alt.       (d)  ?    (0;  20,000)  ft :    '); 

get  list  (chg9)  ; 

if    ((chg9<0)l  (chg9>20000))    then   signal   error  (1); 
end; 

tgt    ptr  =    head->next    ptr; 
tgt~mkr   =    head; 

/*   Now  this   will  find   the   desired   node,    and    make    the 
reguested    changes   on    the    target    data   list    */ 

do    while  (more    =  true)  : 

if    tgt    ptr->num    =    tgt   then    do; 

if    cTo1    =    true  then   tgt   ptr->eq   =    chg2; 
else   do  ; 

tgt    ptr->a   =    chg3 ; 

tgt    ptr->b  =    chg5; 

tgt~ptr->c  =    chg7 ; 

tgt    ptr->u  =    chg4; 

tgt~ptr->v  =    chg6  ; 

tgt~ptr->w  =    chg8; 

tgt    ptr->d   =    chg9; 
end;      ~ 
more  =    false; 
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€nd; 
else  do; 

tgt    mkr    =  tgt  ptr; 
tgfptr    =  tgt_mkr->next   ptr; 
if   Tgt    ptr  =   nail   then  clo ; 
put" skip   list 

('ERROR    :    target    number  not    found1); 
tgt    ptr  =   head->next   ptr; 
tgt"mkr  =   head; 
mere    ■  false  ; 
end; 
end: 
end;    /*  while    */ 
mere   =  true; 

put   skip (2)    list 

(*Dc   you  wish   to   change   another   target?1); 
put   skip    list(»       (Y/N):    '); 
get    list  (cont)  ; 
if   cont  =    'y'    then   cont    =    '  Y' ; 

end;    /*    while   */ 
cont    =    »Y»; 

put    skip  (2)     list  ( 'UPDATING    CHANGED    DATABASE '); 

call    bid    database  (time   in, head); 
revert   error  ( 1)  ; 

end   change; 
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E.        BLDEEASE.PLI 


Prog    Nam€ 

Date 

Written   by 
For 

Adviser 
Purpose 


BLDDBASE.PLI 

May   83 

Todd  B.    Kersh 

Thesis     (AEGIS    Modeling   Group) 

Professor  Kodres 

This   is    the   module  the   builds   the 
database    in   the    Remex  Data    Warehouse    after   the 
Target    List    has    been    created   or   modified. 
V 


bid    database:   procedure    (time    in, head); 
^replace 

true    by   ' 1 •b, 
false    by    •0«b; 

/*   Global  Declarations  */ 

%include    'dbase.dcl'; 

/*   Local    Declarations   *'/ 
declare 

timeend   fixed, 

time_in   fixed    binary(15), 

t    fixed  binary  (15)  , 

trkfull  char(l)    static   init(,H,)# 

i    fixed; 

/*    This    train    procedure   uses   subprocedures    to    build 
the   database    cf   table-8    structures    in   the   Remex    Data 
Warehouse  */ 

t    =   time   in; 

timeend   =  trunc  (endti me/ delta    t)  ; 

do   i    =  time    in   to   timeend; 

call    bld""msg    buff  er  (head,  t)  ; 

call    IcacT    rdw  (t)  ; 

t    =   t    +    1J 

if   trkfull   =    •!■    then    return; 
end ; 

/*    This    procedure   will  create    the   Signal   Processor 
Interface    Simulation    output    message    -co    the   Track 
Processor   Module   for   each   node    of   the   target    list, 
and    store   them    in   a    buffer.    */ 

bld_msg_buf f er :    procedure    ( head, time_in) ; 

declare 

/*    The    Euffer    contains   all   the   track  tables   at    tiioe_in   */ 

1    Euffer    static, 

/*    Table   8;    interfaces   between    the   beam 
stabilization  process   and  the   track   process   */ 


2    B  to    P    tabl(57)  . 

3  x^sub    s  fixed  binary  (15) 

3   y_sub~s  fixed  binary(15) 

3  z_sub~s   fixed  binary  (15) 
3   face   Tdx  fixed   binary(7) 

3   dwl   idx  fixed  binary(7) 

3  trk'num   fixed  binary  (7) 

declare 

bld_buff  entry  (1,2  pointer, 


init  (0)  , 
init  (0)  , 
init  (0)  , 
initjO  , 
init  JO j, 
init  (0) ; 
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2    bit  (16) , 
2  bit(16)  )  ; 


declare 

tiie_in  fixed    binary  (15)  ; 

head   pointer; 


declare 

more    bit ( 

e 

(x,y,z)    float; 


2T6 

ore   bit(1)    static  init(true), 
tr   fixed    binary  (7)  , 
qu   fixed    binary  (7), 


declare 

1    carablk    static, 

2   scurcsbuff   pointer, 

2    destbuff    bit(16)     in  it  (•  5500'  b4)  , 

2   segaddr    bit(16)     init ( 'eOOO 'b4)  ; 

ctr   =    1; 

/*    First    get    the    ncde   of    the  target    data   list    and 
extract   the   data  needed   to   generate   the   items 
on   tbl  8    */ 

tgt   ptr  =    head->next  ptr; 
tgt~mkr  =    tgt_ptr; 

dc    while  (more  =    true)  ; 


buffer. b  to_p    tabl (ctr ). trk_num    =   tgt_ptr->num ; 
equ   =    tgt_ptr->eq; 


/*    Derive    values  for 
at    time_in   for   the   sp 

if   equ  =    1   then   do; 
x=tgt_ptr->a   +    tgt 

y=tgt_ptr->u  ♦    tgt 

z=tgt    ptr->d; 
end ; 

if    equ  =    2   then   do : 
x=tgt_ptr->a  +    tgt_ 

y=tgt    ptr->u  +    tgt 
z=tot~ptr->d; 
end ; 

if    equ  =    3    then  do ; 
x=tgt_ptr->a   ♦   tgt 
y=tgt_ptr->u  +    tgt; 

z=tgt_ptr->d; 
end; 

if    equ  =    4   then   do ; 
x=tgt    ptr->a  ♦    tgt 
y=tgt~ptr->u   ♦   tgt 
z=tgt_ptr->d; 

end  ; 


target   positions   x,y,and    z 
ecified  parametric   equaticn 


_ptr->b*time    in 

tgt    ptr->c*time_in*time 
ptr->  v*£i  me_in 

tgt_ptr->w*time_in*time 


V 

in; 


ptr->b*time_in 

tgt    Dtr->c*time    in*time 
ptr->v*sm  (tgt_ptr-5w*t  ime_ 


in) ; 


ptr->b*cos  (tgt_ptr->c*t ime_ 
ptr->v*time    in 

tgt    ptrr>w*time_in*rime 


in)  ; 


g~_ 


ptr->b*cos(tgt_ptr->c*t ime 
ptr->v*sin  (tgr_ptr->w*tinie 


_in)  J 
_m)  ; 


buffer. b_to  p  tabl 
buffer. b  to  p~tabl 
buffer.  b~to~p""tabl 


ctr)  .  x_sub_s  =  x; 
ctr)  .  y_sub_s  =  y; 
ct  r)  .  z  sub   s    =    z ; 


57 


/*    Set    up    tc  look    at    the   next   target    */ 

ct  r  =   c  tr   *    1 : 

"tgt_ptr  =   tgt  nkr->next   ptr ; 

tgt  mkr   =   tgt~ptr; 

if   fgt    ptr    =  null    then   more    =   false; 
end;    /*dc  while*/ 
more    =    true; 

't<3't_P'tr    ~  head; 
tgt_ikr   =  tgt_ptr; 

/*   This    will    transfer   the    buffer   structure   to    the 
common   memory  board  buffer   location    for   transfer 
to   the    REMEX.    */ 

parablk. scurcebuf f  =   addr(buffer)  ; 
call    tld_buff  (b_ptr)  ; 

end    fcld_isg_buf f er ; 

/*      This    procedure    will   cause   the   REMEX    Data    Ware- 
house  to   load  the   contents    of   the   buffer    into   the 
next    sector   en    the    RBW  hard    disk.    */ 

load_rdw:    procedure  (time_in ) ; 

7 


declare 

time    in   fixed, 
ssnd~mess    entr 


Ssiia    mess    entry, 
build   cidjess   entry    (bit(16),    fixed    binary(15), 

fixed   binary  (15)  , 
fixed    binary  (7)  ,    fixed    binar 
bit  (16)  ,    biz  (16)  , 
fixed    binary  ( 15) )  ; 
declare 

status  fixed   binary (15)     static    init  (0)  , 
sect    fixed   binary  (7), 


y(7)  , 


(256)  , 


head  fixed  binary  (7), 

rdw  read  bit ( 1 6)  static  init (' 1 020 ' b4)  ; 

/*  "1020"  means  the  REMEX  will  write 
from  the  com. mem.  buffer  to  the  hard  disk.*/ 

head  =  0;   /*  this  sets  head  to  "D"  drive  */ 
/*  This  determines  the  sector  based  on  39  sectcrs/track  */ 

sect  =  1  +  mod(time_in,4  0)  ; 
/*  This  determines  the  track  */ 

track  =  1  ♦  trunc  (time_in/39)  ; 

/*  nesd  except,  hndler  for  TRACK  >210  */ 

if  track  >  210  then  do: 

put  skip  list(,The  database  store  is  full.'); 
put  skip  list 

(*   This  run  is  recorded  as  '  ,time_m,  ■  delta_ts.»); 
put  skip  list 
(•   To  create  a  longer  run,  change  the  value  of  delta  t.*); 
trkfull  =  »Y» ; 
return ; 
end; 
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/*    This    procedure   builds   the   command   message   required 
for  the    EEMEX   Data  Warehouse   to  read   the   data   tables 
located    in  the   buffer  corresponding   -co   the   value 
of    "time_in".    */ 

call    tuild  cmd    mess 

(rdw_read, status, track, head, sect, mem,msb, word_count) ; 

/*   The    procedure    sends   the    command   message   to   the   ftemex 
Data    Warehouse  to   perform  the   required   read  operation   */ 

call   send_mess; 

end    lcad_rdw; 

end    bld_database; 
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F.       PBINTLST.PLI 


Name 


Frog 

Data 

Written   ty 

For 

Advi 

Purp 

the 

List 

Data 

*/ 


PRINTLSI.PLI 

May   83 

Toad   B.    Kersh 

Thesis     (AEGIS    Modeling   Group) 
sor  :   Professor  Kodr es 

cse  :   This   module   is    a   diagnostic   tool   for 

user   to    keep  a    record  of  the    flow    of   the   Target 

as   changes    are    made   at    each   delta   t,    as   a  Target 
base    is   constructed   for    a   Static    Model   run. 


printlst:    procedure     (head, time) 
^include    'dbase.dcl'; 

declare 

prt   fixed    bin  (7), 
time    fixed, 
(head,ap,bp)     pcinter; 


put    skip    list('=  =  =    PRINT    TARGET   LIST    ===•) 
retrv: 

put   skip   list  ('To 
put    skip   list ('type 
put   skio   list  (* 
get    list  (prt)  : 
if   prt   °=  0    then 


get   a    print   out.    turn 
<ctrl>    P,    and  then    typ 
Else,     just   type    (Kretu 

go  to  retry; 


on  printer, 
e  0<return>.  ') 
rn>.  ')  ; 


put  skip  (2)  list  ('TARGET  LINKED  LIST  at  time  =  '  ,time) 

ac    =    head; 

bp   =    ap; 

ap   =   bp->next_ptr ; 


do    while  (ap°  =  null) 


bp   = 

out 

put 

put 

put 

put 

put 

put 

put 

pu  + 


ap; 
skip  (2).; 
skiD    list 
skip    list 


'TGT 


skip 

skip 

skip 

skip 

skip 

skib 
put   skip    lis 
ap   =   bp->nex 
while   */ 


list 
list 
list 
list 
list 
list 
lis* 


a  p 

end;    /* 


bp 


=    head; 
=    head; 


at3->num 
• ,ap->e 

'  ,ap->b 
1 ,ap->c 
» ,ap->u 
• ,ap->v 
•  ap->w 
' ,ap->d 


h 


end    printlst; 
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G.       DEASE.DCL 


Prog    Name      :  DBASE.  DCL 

Date  :  May   83 

Written    by    :  Toad   B.    Kersh 

For  :  Thesis     (AEGIS    Modeling   Group) 

Advisor  :  Professor  Kodres 

Purpose  :  These   are  the    global   declarations 

for    the   Target    Database. 

V 


declare 


declare 


endtime 
delta  t 


fixed 
fix  ed 


decimal 
decimal 


8:1) 


external, 
external: 


head  pointer, 
(tgt  mkr,tgt_ 
1  target  base 

2   n  urn 

2 

2 


ptr)    pointer, 

fixed  binary  (7) 
eq  fixed  binary (7) , 
para, 


3  a 

3  b 

3  c 

3  u 

3  v 

3  w 

3  d 

3  e 

3  f 
2  next_ptr 


float, 
float, 
float, 
float, 
float, 
float, 
float, 
float, 
float, 
pointer; 
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BLDB0FF.A86 


Frog  Name 

Date 

Written  by 

For 

;Advi 

Purp 

bu 

me 

pa 

a 

an 


sor 
icse 
ffer 
nicry 


BLDBUFF.A86 

4   June  83 

Todd    E.   Kersh 

Thesis    (AEGIS    Modeling   Group) 

Professor   Kodres 

This    routine    will   transfer    a   256 
from    SBC   private    memory   xo    the   com. 
buffer   starting  at   E000:5100.      The 

I; 


word 


rameter  passed    is  a 'parameter  block   containing 
ointer  to    the    buffer    on    SBC, 


offset  to   the    common    mem.    buffer 


and   -he    base 


Code    Segment 

This  routine    assumes  parameters  as    follows 
paral  Darameter  block   consisting   of 

3   words. 


cseg 

bld_b 
F 

D 

F 

F 

D 

m 
m 
m 
1 
m 
move_ 
i 
m 

i 
i 

i 

1 

P 
p 

F 
P 
P 

r 
end 


words: 
cv  ax, 
ov    es : 


*]. 


ta 


ax 


get    location   of   buffi 

from    para,    passed 
assign    location   of   buff2 

;    assign   no.    of    words    to    move 

lead   word    from  source 
;   sx.ore   word   into   com. mem.    buffe: 
;    adjust   pointers. 


nc   si 

nc    si 

nc    di 

nc    di 

oop      move_words    ;   loop    if   not   done 

cp    es 


cp 
cp 
op 
c 

€ 


cx 

si 
ax 
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APPENDIX    B 
STATIC   MODEL    PROGRAH    LISTINGS 


A.       STATIC. PLI 


Prog    Name      :  STATIC. PLI 

Date  :  8    June    83 

Written   by    :  Todd   B.    Kersh 

For  :  Thesis     (AEGIS    Modeling   Group) 

Advisor  :  Professor  Kodres 

Purpose  :  This    module   controls   the   operation    for 

the    RCP    Static    Model. 

V 

static:    procedure; 

declare 

load    tuffer  entry  (fixed)  , 
xfer~msg    entry, 
advance  avd    entrv, 
display~entry  (fixed)  r 
await   entry    (fixed   bi 


nary(15))  ; 


declare 

start    fixed    binary(7), 

thrshcld    fixed    binary  (15)    static   init(1), 

endtime   fixed    external, 

item  fixed  binary(7), 

evcvalue  fixed  binary (15)  static  init  (0)  external, 

tiire    fixed; 

/*      This   exceDtion   handler    will  take   care   of   all 
user    input  errors.    */ 


on  error  (1) 
begin ; 

put   skip    list  (»ENT  BY    ERROR,     TRY    AGAIN. 

gc   to    retry; 
end ; 


•)  ; 


'/ 


put    skip  (ascii(26)  ,ascii  (30))  ;    /*    clr.    screen 

put    skip    list  (•  ===    RSP    STATIC    MODEL    ="'); 

put    skip    list  (»  version    1.0  June    83'); 

put   s k i p  ( 21  ; 

put   skip   list  (•  At    this   pcint   you   should    have   created 

a    database   and   are    now   ready  to    run') ; 
put   skip   list  ('your  test    of  the  NPS    SPY-1A   Model.'); 
put   skip  (2)  ; 
retry : 

put    skip    list('     =  =  =    STATIC    MODEL    MENU    ==='); 
Dut    skip    list  (•  (1)    TEST    run   the  simulation*)  ; 
put    skip    list  ('  (2)    QUIT    and    return   to   main    menu'); 
put   skip   list  ('enter    1-2    and   <cr> :    '); 
get   list  (item)  ; 
if    (  (item<1)  |  (item>2)  )    then   signal   error  (1); 

if    item    =   1    then    do; 

put    skip    list  ('Load   SPYTEST.CMD    from    another 

system    CRI/SBC. • ) ; 
put   skip    list  ('When   complete,    enter    0<cr> 

to   begin    =>    ')  ; 
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get    list (start) ; 
if    stana  =  0   then 


signal   error  (1)  ; 


e 
end; 
else 


do   tine  =    1   to   endtime: 
call   await (thresho Id) ; 
threshold    =    threshold   + 
call  load    buffer  (time)  ; 
call  xfer~msg; 
call  advance  evd; 
call  displayltime)  ; 


nd 


return; 


revert   error  (1)  ; 
end    static; 
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B.   AW1IT.A86 


Prog  Name 
Date 

Written  by 
For 

Advisor 
Purpose 
written  to 
Scheduler. 


AWAIT.  A86 
8  June  83 
Todd    B.    Kersh 

Thesis    (AEGIS    Modeling    Group) 
Professor   Kodres 
This    module  checks   to    see    if 
0E000:56  14  of  common    memory    by 


a    msg    has 
the  Radar 


been 


EftTA 


CODE 


cseg 
public 

await : 

push 

push 

push 

push 

HlOV 

await 


ax 

di 
si 
es 
ax,Ce000h 
mov   es,ax 
mcv    di,06020h 
mov   si,[fcx] 
lcds   ax 
poll : 

ax,es:[  di  ] 

poll 
es 
si 
di 
ax 


end 


cmp 
jnz 

pop 
pop 
pop 

POP 

ret 


;    get   common    mem.    base 
;    assign   to  eseg    base 
;    point   to   eve   addrs. 
get    threshold 
;    put   it   in  ax   reg. 

compare   eve  to   thr 
;    if    no    new   msg,    wait 
:    else    return 
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C.       LCADEOFF.PLI 


Prog    Name 

Cate 

Written   by 

For 

Adviser 

Purpose 


LOADBUFF.PLI 
3  1    May    83 

Todd   B.    Kersh 

Thesis     (AEGIS    Modeling   Group) 

Professor  Kodres 

This   module   is    part    of   the    Static  Model 


and    will   extract  the    proper    sector  of   output   msgs     (e.g. 
tbl_8s)     from  the   database  on  the   Remex   DW,    based   on    the 
current    value  of   delta  t,    and    place   the    data    in   the 
commen    memory  buffer.  *" 
*/ 

load_fcuffer:   procedure  (time^in)  ; 

declare 

time    in  fixed, 
send"~mess    entry, 
builc_cma"_mess  entry    (bit  f  16)  ,    fixed   binary  (15)  , 

fixed   binary ( 15) , 


fixed   binary(7),    fixed    binary  (7)  , 
bit  (16)  f   bit  (15  | - 
fixed   binary  ( 15) ) ; 


declare 

status  fixed    binary  (15)    static    init(O), 

sect  fixed  binary(7), 

word  count  fixed  binary  (15)  static  init  (256)  , 

mem  b"it(16)  static  init  ( '5500'  b4)  , 

msb  bit(16)  static  init  ( '000a*  b4)  , 

track  fixed  binary (15) , 

head    fixed   binary(7)  . 

rdw    wrt   bit(16)    static   init  (•  10  10  •  bU)  ; 

"/*  "10 10"    means  the    REMEX   will   read   the 

hard    disk    and    write    to   com. mem.    buffer.    */ 

head   =   0 ;   /*    this   sets   head  to   »D"    drive   */ 

/*    This   determines   the   sector   based   on    39  sectors/track   */ 

sect    -    1    +  mod  (t  ims_in,4  0)  ; 

/*   This   determines   the  track   */ 

track   =    1   +    trunc  (time_in/39)  ; 

/*    Max   tracks   available    on   the   REMEX    is    210 
therefcr,   to    prevent   running   out   of   memory...*/ 

if   track   >   210  then  do: 

put   skip    list ( 'The   database   store    is    full.1)  ; 
put   skip    list 

(•      This    run    is  recorded   as    ,,time_in,'    delta  ts.')  ; 
put   skip    list 
To   create  a    longer  run,    change  the    value    of   dslta_t.t); 
return; 
end ; 

/*    This    procedure   builds    the   command   message 
required    for    the    Remex   Data   Warehouse   to   write    the 
data    tables    located  in  the    buffer    corresponding 
to   the   value    of    • time_in '    */ 

call   tuild_cmd   mess 

(r  dw_wrt ,  status,  track,  head,  sect,  mem,  msb,  word_count)  ; 


/* 

Re 


The  procedure  sends  the  command  message  to  the 
mex  Eata  Warehouse  to  perform  the  required 
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writs   operation    */ 
call    send  mess; 
end    load   fcufrer; 
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D.       XFEB.A86 


Prog   Nam* 
Date 

Written   by 
For 

Advisor 
Purpose 
rhe    common 
0E000:5646 


Data 


XFER. A€6 

8    June    83 

Todd    B.    Kersh 

Thesis     (AEGIS    Modeling    Group) 

Professor   Kodres 

This    module  will   transfer    a   output    msg.from 
memory    buffer  to   the   common   memory  location 
to    be  read  by  the   Track   Processing   Module. 


Code 


cseg 

public   xfer_msg 

xfer_msg: 
push    di 


push 

si 

push 

ss 

push 

ds 

push 

ax 

push 

f 

mov 

axf  OeOOOh 

mcv 

es,  ax 

mcv 

si,C5500h 

mcv 

di,06055h 

mov 

ex,  5 

move    msq 

: 

mov 

ax,es: [si] 
es:  [  di j , ax 

mcv 

inc 

si 

inc 

G  * 

inc 

di 

ire 

di 

loop 

mo  ve_msg 

pep! 

pop 

ax 

pep 

ds 

pep 

as 

pep 

c  j 

pop 

di 

ret 

; get  common  mem.  base 
; assign  to  eseg 

; set  loop  ctr  to 
;  pass  5  words 
;  (one  tbl_8)  . 

;load  word  from  buffer 
;stora  word  into  msg. 
; get  next  word  loc. 

; get  next  word  loc. 

;loop  until  done 


end 
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E.   DISPLAY. PLI 


Frog 

Date 

writ 

For 

Advi 

Purp 

simu 

user 

NPS 

V 


Name 
en  by 


DISPLAY. PLI 

8  June  83 

Todd  B.  Kersh 

Thesis  (AEGIS  Modeling 

Professor  Kcdres 

This  will  display  the  status 


Group) 

scr 
ose 

laticn    for    the    RSP  Stat ic* Model,    and   allow  the 

to    make  measurements  tc   determine  the   speed   cf 
SPY-1A    Model   execution. 


of    the    test 


the 


display:    procedure    (time); 

declare 

time    fixed, 

endtime   fixed    external; 

/*put    listjfascii  (26)  ,ascii  (30)  )  :*/ 

put  skip  list('    ===  RSP  STATIC  MODEL  SIMULATION  = 

put    skip  (2)  ; 

put    skip    list  ('TIME:  •,  time,  <      ENDTIME  :',  en  itime)  ; 

end    display; 


=='); 
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F.       ADV1EVC.A86 


Prog  Name  : 
Dare  : 
Written  ty: 
For  : 
Advisor  : 
Purpose 
Signal 
SPY-1A 


ADV1EVC.A86 
8    June    83 
Todd   B.    Kersh 

Thesis     (AEGIS    Modelling    Group) 
:  Professor  Kodres 

:    This    module    will    simulate   the    Radar 
Processor  sending  a    new   data    msg   to   the 
Cctrcller   Model. 


Data 


Cede 


cseg 
public 


advance    eve  1 


advance   evd: 

PUS'S     €S 

push  di 
push  ax 
mcv    ax, 

mcv 
mov 
mcv 
inc 
mcv 
pop 
pep 
po 
re 
end 


OeOOOh 
es,ax 
di,06055h 
ax,es:  [  di] 
ax 

es: [ di  ] ,  ax 
ax 
di 

ee 


;    get    com.    mem. 

;    point   to  evd 
;    get    value 

;    increment    value 
; store  evd 


base   to    -sag 
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APPENDIX  C 
COMMON  ASSEMBLY  LANGUAGE  LISTINGS 


A.   ELDMESSG.A86 


Prog 
Date 
writ 
For 
Advi 
Purp 
co  mm 
Ware 
o  per 
fell 
b 


Name 


tten  by 


sor 
cse 


BLDMESSG.A86 
May   83 

Todd    B.    Kersh 

Thesis    (AEGIS    Modeling    Group) 
Professor   Kodres 
.    This    primitive   module   is   a   general 
and   msq.    passing  routine   to   the    Remex   Data 
house, "to    be   used  for    both    Write   and    Read 
ations.      It  expects   to    get   parameters   as 
cws    frcm  the  calling   Pit    program: 
uild    cmd  mess (wcrd    0,    word    1.    word    2, 
wcrd    3   high   byte,    word    3 
lew   byte,    word   4,    word   5, 
wcrd   6) 


DSEG 
ESEG 
EUBL 


Data  Segment 


CCMMEM  EQO 

CRG  5400H 
IC   STATUS 

MODIFIERS  RW 

STATUS  RW 

TRACK  NO  RW 

BEAE  SECT  RW 

MEM  IDDR  RW 

MSB"  RW 

WORD  CNT  RW 


0E000H 


Cede  Segment 


CSEG 

PUBLIC       EUILE_CME_MESS 

EUILD    CMD    MESS: 
~       ETJSH   ES 

FCSH   CX 

EUSH   SI 

FCSH   BX 

EUSH    AX 

ECSHF 
MOV    AX,COMMEM 
MOV    ES,AX 

CLD 

MCV    SI  ,[  BX] 

LCDS   AX 

MCV    MODIFIERS, AX 
aED    EX,0  2H 
MCV    SI  ,[  BX] 

LODS  AX 


set  source  index  to  point 
;  to  1st  parameter. 
;  AX  =  para  1,  SI  incremented 
;  to  pornt  to  next  parameter. 

; point  to  next  parameter  address 
set  source  index  to 
; point  to  next  para. 
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MCV    STATUS,  AX 
ADD    BXr0  2H 
MCV    SI, [EX] 

LCDS    AX 

MCV    TRACK    NO  ,    AX 

ADD    EX,0  2E 

MCV    SI,[  BX] 

LCDS    AL 

MCV    AH,AL 

ADD    EX,0  2H 

MCV    SI  ,[  EX] 

LCDS    AL 

MOV    HEAD    SECT, AX 

ADD    BX,0"2H 

MOV    SI  ,[  BX] 

LODS    AX 

MCV    MEM     ADDR,AX 
ADD    BX,U2H 
MCV    SI,  [EX] 

LCDS    AX 
MCV    MSB.AX 
ADD    EX,0  2H 
MOV    SI  ,[  BX] 


;  point    to   next   parameter    addrsss 
;set  source   index   to   point 
; to   next  para. 


;    point    to   next    parameter   address 
; set    index   to    point    to   next    para, 
get   byte   para   in  al  rea. 
move   al   to   ah 


LCDS   AX 

MCV 

WORD 

POPF 

PCP 

AX 

PCP 

BX 

PCP 

SI 

POP 

cx 

PCP 

ES 

;word   is   now    complete   for    movement 

; point   to   next   parameter   address 
;set   source   index   to 
;point   to    next    para. 

; point   to   next   parameter    address 
;set   source    index" to 
;point   to    next   para. 

; point   to   next    parameter   address 
;set   source   index   to 
;point   to    next    para. 


CNT,AX 


END 


RET 
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E.   SHDMESS1-A86 


Prog  Na&e   :  SNDMESS1.A86 

Date  :   May   83 

Written    ty    :    Todd    B.    Kersh 

For  :    Thesis    (AEGIS    Modeling    Group) 

Advisor  :   Professor   Kodres 

Purpose  :    This    primitive   module    sends   the   command 

message   located  in    common    memory   at    0E000:5000    to   the 

Eemex   Data   Warehouse   for  execution.      It   checks    the 

Status    Word  in    the    msg.    for   successful    msg   completion. 


DSEG 


Eat  a    Seament 

—  —  —  - 

- =  =  —  == =  —  — =  —  — — : 

-———— 

EDW    EEEOE 

EDW'BESULT 

BDW~EIR 

SUCCESS 

FAILURE 

EDW    BEADY 

TRIES 

DB 

DB 

DB 

EQU 

EQU 

EQU 

EQU 

;      EDW    interface 

cent 

EDW 
EDW" 
REW" 
BEW" 

CME    REG 
"STATUS     REG 
'ADDE    LU 
'ADER""HI 

EQU 
EQU 
EQU 
EQU 

1 

1 
1 
1 

0 

08H 
05 


;  code 
;code 


for 
for 


opn 
opn 


success 
failure 


; constant 


ports  ==> 


70H 
71H 
72H 
73H 


ESEG 
EXTRN 


STATUS  :WORE 


Code    Segment 


CSEG 
PUBLIC 


SEND    MESS 


SEND 


SEND 


MESS 
POSH 
PESH 
POSH 
POSH 
MCV 
MCV 
MCV 
EDW 
'IN   A* 
AND 


AX 
ES 
C  X 

AX,OE000H 

EX  ,AX 

CX,TRIES 

MESS: 

L.RDW    STATUS     REG 

AL,RDW~    READY" 


;init.    loop   counter 


CMP 
JNE 
MOV 
CUT 
MOV 
OUT 
MOV 
CUT 
CHECK  BDW 
HCV 
CMP 
JE 
CMP 


AL,08H 

SEND    REW    MESS 

AL,1CH      "" 

EDW    CME    REG,AL 

AX,U54  0T)H 

EDW    ADEE    LO,  AL 

AL  ,A"H 

PDW    ADEB    HI,AL 

RESULT:" 
IX, STATUS 
AXrSUCCESS 
BDW    SUCCESS    READ 
AX,FAIL0RE    " 


;check   if   interface    ready 
;to   process    cmd   packet... 
;ready? 

; if  not  repeat 

;load  extended  address 

;offset  of  packet 
;transfer  low  byte 

;transfer  high  byte 

;read  status  word 
;check  for  success 

check  for  failure 
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JNE    RDW    RETRY 

JKPS    CHECK    BDW    RESULT 
BDW    RETRY; 

~   MCV   RDW  ERECR,AL  ;save    error   code 

MCV  STATUS, 0  ;clear    status   word 

LOOP    SEND    RDW    MESS  ;loop    if    counter    <>    0 

MOV    RDW   RESULT, OFFH  jreturn    failure    code 

JMPS    RDW    EXECUTE     RET 
RDW    SUCCESS     RSID: 

MCV   RUW   RESULT, 00 H  ;return   success    code 

RDW    EXECUTE  SET  : 
"    POP   CX~* 

POP    ES 

POP    AX 

PCPF 

RET 


END 
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APPENDIX    D 
SPY-1A    MODEL   SIMULATION    PROGRAM    LISTINGS 


A.       SPYTEST.PLI 


/* 

Prog    Name 

Date 

Written   by 

For 

Advisor 

Purpose 


SPYTEST.ELI 
8    June    83 
Todd   B.    Kersh 
Thesis     (AEGIS 
Professor  Kodr 
This   is    a   test 
operation   of  the   NPS    SPY-1A 
tabl    58    data  in    common  memo 
from~the    Static    Model,    afte 
the   operation  of   the    Track 
V 

spy_test:    procedure; 

declare 

init   entry, 
advance  evc2    entry, 
threshold    fixed   bm(1 
awaitl   entry    (fixed   b 
i    fixed  binary    (15)  ; 


Modeling   Group) 
es 
module   that    simulates    the 
Model.      It    will   update    the 
ry   upon  the   event   count    update 
r   a    delay    loop    that  simulates 
Frocessor   and   Radar  Scheduler. 


5)     static    init  ( 1)  , 
inary  (15) )  , 


/*   This    will    initiate  the   eventcounts    to   0   */ 

call  init; 

do  while  (•  1  •  b)  ; 

call   advance_evc2;    /* 

call   await  1  (threshold 


This   simulates    sending    a    new 
dwell   cmd.    msg.    */ 
) ;    /*    wait    for   results 
e.g.    tbl_3    */ 


/*   This  is   a    delay   lo 
processing  time.    */ 

threshold    =  threshold 


op    simulating   SPY-1A    Model 
♦    1; 


do    i    =   1    to    50; 

put   skip    list('SPY-1    IS    PROCESSING    DATA »); 

end  ; 

end;    /*    while   */ 
end    spy__test; 
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E.   IHIT.A86 


Prog  Name 

Date 

Written  by 

For 

Advisor 

Purpose 


INIT. A86 
19   June    83 

Todd    B.    Kersh 

Thesis    (AEGIS    Modelina   Group) 

Professor   Kodres 

This    module   initiates   the 


memory    locations  for  the  eventcounts   to    0. 


Data 


a 


seg 


eseg 
public 


eve  1  fe  vc2 

org    06  0  2  Oh 
evc2     rw 
evc1      rw         1 


Code 


cse 

lie 

pub 

ini 

"push 

push 
mcv 

mcv 

mcv 

mov 

mcv 

pep 
pep 
ret 

init 


ax 

es 

ax,0e000h 

es ,  ax 

ax  ,0 

evd,  ax 

evc2r  ax 
es 
ax 


;set   exeg    base   to   com 
;set   ax  to   0 

;set    eventcounts   to   0 


mem 


end 
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C.   AHAIT1.A86 


Prog  Name 
Date 

Written  by 
For 

Advisor 
Purpose 
been  updated 
Radar  Signal 


AWAIT1  .A86 

8    June    1983 

Todd    B.    Kersh 

Thesis 

Professor   Kodres 

This    module  checks   to   see    if   an   eve.    has 

at   0E0C0:5616    of    common    memory   by   the 

Processor   Simulator. 


Data 


iseg 


eseg 

exxern      eve  1  tword 


Cede 


eseg 
public 


awaitl 


await  1 : 

push    si 
push    ax 
push   es 
mov    axr0e000h 
mcv    es,ax 
mov   si,<"  bx  ] 
leds   ax" 


poll 


end 


emp 
jnz 
pep 
pep 

III 


ax.  eve  1 

pell 

es 

ax 

si 


;    get    com.    mem    base    in   eseg 
get    parameter   -    threshold 
;    load   it   in    ax    reg. 

;    compare   eve    to   threshold 

;    if   no   new    message  sent,    wait 

;    else,    re-urn 
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D.        ADV2EVC.A86 


Prog    Name  :  ADV2EVC.A86 

Date  :  19  June   83 

Written   by  :  Todd    E.   Kersh 

For  :  Thesis    (AEGIS    Modeling    Group) 

Advisor  :  Professor   Kodres 

Purpose  :  This    module    will   simulate   the    Rada: 

Scheduler   sending   a   new   dwell   command  to   the   RSP 


Eata 


dse< 


eseg 

extrn      evc2:word 


Cede 


cseg 

public 

Advance_evc2 

advance 

evc2: 

pusli 

€S 

push 

ax 

mcv 

ax,  OeOOOh 

mov 

es,ax 

• 

get    ad 

dr.    o 

f 

i 

in 

eseg 

inc 

evc2;    advance 

event  count 

pep 

ax 

pop 

es 

r€* 

coram. mem.    base 


end 
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APPENDIX    E 
OBJECT-ORIENTED    DESIGN    OF    THE    DYNAMIC    MODEL 

A.  DEFINE    THE    PROBLEM 

A  system  is  required  that  will  interface  with  existing 
SPY-1A  Padar  Controller  modules  and  simulate  the  Signal 
Processor  of  the  Radar.  The  required  interface  will  actu- 
ally include  the  Radar  Output  Module  and  the  Radar  Return 
Module,      and     the   Beam      Stabilization   Modules.  The   Signal 

Processor  Simulator  must  contain  a  database  representing  the 
environment  the  Radar  will  probe  for  target  tracks.  The 
database  must  be  user  changeable  at  any  given  time  during 
the  operation  (i.e.  add  target  tracks,  delete  target  tracks, 
and  change  target  tracks)  so  that  the  logical  operation  of 
the  SPY-1A  Radar  Modules  (Radar  Scheduling  and  Track 
Processing)    can    be    tested   and   explored. 

B.  DEVELOP    AN    INFORHAL    STRATEGY 

The  database  for  the  signal  processor  will  capture  the 
information  for  each  target  at  discrete  time  intervals 
needed  tc  define  it's  position.  The  information  maintained 
about  each  target  track  will  include  it. f  s  actual  position 
(x,y,z,r)  and  it's  acceleration  components  (ax, ay  ,az  ,ar)  at 
a  discrete  time  interval  (t) .  Interaction  operations  that  a 
user  may  request  include  -  initiation  of  a  target  track  over 
a  range  of  time  (Ti  — >  Tn) ,  deletion  of  a  previously 
entered  target  track  throughout  all  or  part  of  it's  initi- 
ated range  of  time,  and  changing  a  previously  defined  target 
track  at  any  time  during  it's  pre-defined  time  range.  The 
user  will  also  be  able  to  start  and  stop  the  simulation  at 
any    time.        The    user    will  have      a  two    dimensional    display   of 
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the  radar  environment  with  current  tracks  and  relative  posi- 
tions symbolized  during  the  simulation.  A  status  report  of 
current  targets  will  be  available  while  in  a  non-running 
mode    tc    assist    the    user   in    the   environment    definition. 

C.       FORMALIZE   THE    STRATEGY 

1  •      Identify   the   Objects  and   thsir    Attributes 

a.     SIMULATION_OPERATTONS 
t.    TRACK_DAT2: 

Target  Information: 

target_lD 

actuai_ position 

acceler  ation 

time 

2  •      Identify   Operations    on  the  Objects 

a.  SIMULATION_OPERATIONS 

b.  DISPLAY: 

Start 
Stop 

c.  TRACK_DATA: 

Sta tus_Repcr t 

Quit 

Target_Infor  mat ion: 

create 

delete 

change 
Database 
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3  •   Establish  the  Interfaces 


SIMULATION  OPNS- 
( subprogram) 


SIMULATION  OPNS 
(packagef 

create  tgt 
delete~tgt 
change~tgt 
status~rpt 
quit 


TRACK  DATA 
(package) 


TGT_INFO 
(packag  e) 

tgt_rscord 


DISPLAY 
(package) 

start 
stop 


DATABASE 
(package) 
acti ve_records 
data 


Figure    E. 1        Object-Oriented   System   Graph. 


Cede  the   Package   Specifications   in    Ada 


cackaae    TRACK   DATA    is 
package    TG~T_INFO    is 

end    TGT_INFO; 

package    DATAEASE    is 

end    ESTAEASE; 
end    TRACK_DATA; 

package    TGT    INFO    is 

type    ENt>  TIME   is    constant    :=    1000; 

type    COORDINATES    is     (X,Y,Z,R): 

type    ACCEL    VECTORS   is    (  AX,  AY  ,  AZ  ,  AR)  ; 

type    EISCRETE_TIME  is   range    ..    END   TIME; 
type    TARGET    is    record 


LCCATION 
ACCELERATION 
TIME 

end   record; 
end    TGT_INFO; 


COORDINATES; 
ACCEL    VECTORS; 
DISCRETE    TIME; 
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package    EATABASE   is 

use    TGT    INFO; 

MAX    RECDRDS      :       constant    :=   20; 

type    FECCRD    INDEX  is   range   0    ..    MAX    RECORDS; 

typa    TRACK    "RECORDS    is   array    (RECORD"INDEX)     Of    TARGET; 

ACTIVE    TGT5       :       RECORD    INDEX; 

DATA      "  ;       TRACK   "RECORDS; 

end    DATABASE; 

with  TRACK  EATA; 
use  TRACK~DATA; 
package    SIMULATION    OPNS    is 

type    OPERATICN~is    (CREATE    TGT, DELETE    TGTrCHANGE    TGT, 

STATUS~*RPT,QUIT)  ;~ 

function  GET   return   OPERATION; 

procedure  CREATE    TGT; 

procedure    DELETE~TGT; 

procedure   CHANGE^TGT; 

procedure   STATUS    RPT ; 

procedure  QUIT; 
end    SIMULATICN_OPNS; 

with  TRACK  EATA; 
use  TRACK"*EATA; 
package    DISPLAY    is 

type    CONTROL    is      (START,  STOP)  ; 

function  RUN   return   CONTROL; 

procedure   START; 

procedure  STOP; 
end    DISPLAY; 

Further  programming  would  design  and  build  the  subprograms, 
functions,  and  procedures  defined  by  these  package 
specifications. 
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APPENDIX  F 
SIGNAL  PROCESSCR  MODEL  USEES  HANOAL  (VER.1.0) 

A.   GENERAL 

This  manual  is  for  use  with  the  NPS  AEGIS  Modeling  Group 
AN/SPY-1A        Radar     Controller        Model:  Signal        Processor 

Emulation  version  1.0.  It  does  not  explain  the  structure  of 
the  modules  that  make  up  the  program,  only  it  * s  functional 
components  and  how  they  might  be  utilized  to  -est  the  SPY-1A 
Model.  For  further  information  about  the  program  design  and 
implementation,  see  Kersh,T.B.,  Signal  Processor  Interface 
Simulation  of  the  AN/SPY-1 A  Radar  Controller,  Masters 
Thesis,    Naval  Postgraduate    School,    Monterey   California    1983. 

The  manual  is  divided  into  the  two  major  functional 
areas:  developirg  the  target  database  to  be  stored  in  the 
REMEX  Data  Warehouse,  and  running  the  Static  Model  of  the 
Signal  Processor  against  a  simple  SPY-1A  simulator.  It  will 
be  assumed  that  any  potential  user  of  this  system  is 
familiar  with  the  boot  procedure  for  the  Remex  Data 
Warehouse    disk    system.  Assuming  the    user   has      booted    from 

the  REMEX  B:  drive  and  logged  into  the  REMEX  D:  drive,  place 
the    Signal    Processor   system    disk    in   the   C:    drive,    and   type: 

D>C:RSP    <return> 

At  this  point  the  Signal  Processor  Emulation  System  will 
load  and  the  remaining  database  development  and  model  opera- 
tion   will    be   menu   driven. 

The    following   functions    are      available   within   the   Signal 
Processor   Interface    Simulation   - 
TARGET    DAIAEASE: 

1.      CREATE  the   inital   target-list    and    initial    database. 
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2.  DELETE  any  targets   at   any   specified   descrete   time. 

3.  CHANGE  the  parameters  of  the  parametric  equations 
representing  the  target  tracks  at  any  specified 
descrete    time. 

4.  FBINT  the  current  target-list  re  the  terminal  screen 
cr  the  printer  at  the  specific  descrete  time  repre- 
sented by  the   target-list. 

SIMULATION: 

1.  RUN  will  execute  the  Static  Model  in  a  test  environ- 
ment to  be  used  for  testing  the  Signal  Processor 
Interface  Simulation  System. 
After  development,  the  user  can  document  the  targets 
contained  in  the  tarcet-list  at  a  particular  descrete  time  , 
so  that  he  has  a  hard-copy  record  of  the  trend  of  his  data- 
base. This  feature  will  be  important  in  determination  of 
the  effect  cf  different  target  combinations  and  densities  on 
the  SEY-1A  Controller  Model.  The  Signal  Processor  Interface 
Simulation  Target-Database  development  system  should  be 
usable  in  cenjuction  with  ether  testing  systems  devised  by 
future  AEGIS  Grcup  members  for  the  logical  testing  of  the 
SPY-1A   system. 

E.       CONSTRUCT    TARGET    DATABASE 

1 .      £ain  Menu 

Just  prior  to  the  display  of  the  main  menu,  the 
program  will  ask  for  user  input  defining  the  descrete  time 
intervals  to  be  used  for  the  update  of  the  buffer  used  by 
the  Target-Database  system.  The  ratio  of  dwell  commands 
received  from  the  Radar  Schedular  Module  to  the  target- 
buffer  update,  multiplied  by  the  actual  turnaround  time  of 
the  SF-1A  Controller  Model  will  be  the  real-time  achieved  by 
the  system.  The  user  may  assign  values  from  .1  to  1  to  this 
ratio    value.  The    next    question   asked      of  the    user      is   how 
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long    ths   sinulation    will   run.  The    maximum    possible   length 

is  dependent  on  the  storage  space  available  on  the  REMEX 
Data  Warehouse,  and  the  time  is  based  on  the  average  assumed 
dwell  command  interval  time  received  from  the  SPY-1A  Radar 
Controller  Model.  To  determine  the  simulation  run  limit  in 
terms  of  descrete  time  increments,  one  must  realize  that 
each  descrete  time  increment  is  in  one-to-one  correspcndance 
with  the  sectors  used  to  record  the  database  on  the  REMEX. 
Therefore,  since  there  are  39  sectors  per  track,  and  210 
tracks  available  for  use,  there  are  8190  available  descrete 
time  intervals  available  for  a  simulation  run.  The  real-time 
length      for   the      simulation      run    is      then      dependent   on      the 


***    MAIN   MENU    *** 

What    course    of  action   do    you   wish? 
(1)       CREATE   a    database   of   tracks 
(you    must    do   this    first) 

!2)      DELETE   a    track   from   the  database 
3'\      CHANGE   a   track  on   the   database 
4)       PRINT  the   current   target    list 

After   a    database    is   satisfactory   you   may: 

(5)  RON      a   simulation 

(insure    the  rest    of  the  SPY-1    Model   is    setup) 

(6)  QUIT    and    return    to   the  operating  system 
(enter    1-6  and   <cr>)  : 


Figure   F. 1        Signal   Processor  Emulation    Main   Menu. 

descrete      time      ratio.  Assuming      a      negligible      time      for 

updating  the  target  buffer  from  the  REMEX,  and  a  turnaround 
response  time  from  the  SPY-1A  Controller  Model  of  .001 
seconds,  if  a  ratio  of  "1"  were  chosen,  the  maximum  time 
available   for   a    simulation    run    would    be: 
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1.  "1"  second  =  .001  sec.  *  1000  (or  1000  dwell  commands 
issued  per   buffer   update) 

2.  since  the  target-buffer  is  updated  once  every  second, 
there  are  8190  seconds  of  maximum  simulation  time 
available. 

The  next  item  appearing  on  the  screen  is  the  Main 
Menu.  The  first  thing  required  is  to  build  a  database  in 
the      REMEX   Data      Warehouse.  To  dc      this,        the    user      will 

initially  pick  choice  (1)  CREATE.  After  initializing  his 
Database,  the  user  be  able  to  move  forward  in  descrete  time 
and  delete  target  tracks  completely,  or  just  change  the 
parameters  cf  the  track.  It  is  suggested  that  the  user  use 
option  (4)  PRINT  after  each  iteration  of  the  previous  two 
options  and  after  CREATE,  to  maintain  a  record  of  the  modi- 
fications made  on  the  database.  When  the  user  has  finished 
with  his  Target  Database,  he  may  request  to  (5)  RUN  a  Static 
Modal  simulation.  In  this  mode  the  SPY-1A  Controller  Model 
Simulator  "SPYTEST"  is  designed  to  test  the  Static  Model. 
Further  instructions  en  the  use  of  this  option  are  discussed 
in    Section   C.  Of    course,      at   any  time   after     the   user   has 

returned  to  the  Main  Menu,  he  may  choose  option  (6)  QUIT  to 
return   tc   the  operating   system. 

2-      Create    Database 

To  use  the  Signal  Processor  Interface  Simulator,  a 
Target-Database  must  first  be  constructed.  A  Target-List  is 
used  which  contains  target  data  to  construct  a 
Target-Database.  The      parameters      used        to      set      up      the 

Target-List  for  each  target  are  the  constant  values  used  in 
the  parametric  equations  shown  in  Figure  F.3  These  parame- 
tric equations  derive  from  Boone,  N.A.,  A  Mul ti mi cr processor 
Approach  to  simulate  I/O  for  the  AEGIS  AN/SPY-1 A  Radar 
Controller,  Masters  Thesis,  Naval  Postgraduate  School, 
Monterey      California,         198  1.        Boone's      work      concerns      the 
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===    CBEATE   TARGET    MODULE    === 
Initiate   target    # 


(b)  ?    (-32, +32) 
Y~velocity    (v)  ?    (-32,  +32)  m'/sec: 
X_acceleration 
Y   acci 
Z"alt: 


:eleration  (c)  ?  (-.  0  15625,  +  ."0T5625)  m/sec/sec: 
:eleration  (w)  ?  ]  -.0  15625,  +  .  015625)  m/sec/sec: 
itude    (d)  ?    (0,20000)ft:  


create   more    targets?  (Y  or   N)  : 


Figure    F.2        CBEATE    Function   Menu. 
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i 

a 
u 

a 

+ 
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= 

a 
u 

+ 
+ 

b*cos  (c*t) 
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W 

xm 

z  (t) 

a 

a 
u 

a 

+ 
+ 

b*cos  (c*t) 
v*sin  (w*t) 

Figure    F.3        Parametric    Equations. 

simulation  of  the  AEGIS  Command  and  Decision  functions,  and 
these  equations  were  utilized  to  maintain  compatiblity 
throughout  the  Mcdel.  After  defining  the  parametric  equa- 
tion   for      the  first    target,      the      user   may   choose      to   define 
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further  targets  and  will  be  prompted  similarly  as  previously 
shown.  When      he      is  satisfied     -hat      the      target-list      is 

complete,  he  may  indicate  that  no  more  targets  are  to  be 
created,  and  he  will  te  returned  to  the  Main  Menu.  At  that 
time  it  is  recommended  that  the  user  request  a  PRINT  of  the 
initial   target-list    for   future   reference. 

3  •      Delete    Targets 


— i 

=  =  =    DELETE    TARGETS    MODULE    === 

WHAT    TARGET    DC    YOU    WISH    TO    DELETE?    ■ 
(TGT.     NUM.     RANGE    1- ): 

, 

Figure    F.4        DELETE    Function   Menu. 

Frier  to  the  Delete  Menu,  the  user  will  be  asked  "At 
what  time  do  you  want  to  delete  a  target?".  The  user  is 
being  asked  to  define  the  descrete  time  within  his  previ- 
ously defined  range  of  descrete  time  that  he  wishes  to 
delete  a  previously  defined  target.  It  is  important  tha-1:  the 
user  have  developed  a  plan  for  target  modifications  based  on 
his  defined  descrete  time  range,  since  the  Target-Database 
development  routine  will  not  allow  one  to  recover  deleted 
targets.  After  answering  the  time  question,  the  Delete  menu 
will  be  displayed,  and  the  target  list  appropriately 
updated.  After  Deleting  a  target,  the  user  will  be  prompted 
to  "continue  (Y/N)?".  He  may  answer  Y  (es)  to  delete  more 
targets    or    N(o)     to    return  to   the   Main   Menu. 
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4  •      Change    Targets 

Tte  Change  choice  from  the  Main  Menu  will  first 
Frompt  the  user  requesting  what  time  he  wants  to  change  a 
target,  within  his  predefined  descrete  time  range.  After 
answering,      the      user  will    see      the   Change   menu       (see   Figure 


■»■    CHANGE   TARGETS    MODULE    === 

WHAT    IS    THE    TARGET    NUMBER    YOU    WISH    TO    CHANGE? 
(TGT.NUM.    RANGE    1- ): 

WHAT    CATA     ITEM    IS    TO    BE    CHANGED? 

(1)  PARAMETRIC    EQUATION 

(2)  EQUATION    PARAMETERS 

(if   the    choice   is    one,    then:) 

WHAT    IS    THE    NEW    EQUATION    NUMBER     (1-4)?    

(if   the    choice   is    two   then:) 

WHAT    ARE    THE    NEW   PARAMETERS: 
X_range    (a)?    (-256  ,+256)  nm: 


Z_alt.     (d)  ?     (0,200  00)  ft: 

(and    fcr    either    choice..) 
DC    YO0    WISH    TO    CHANGE    ANOTHER    TARGET? 
(Y/N)  : 


Figure    F.5        CHANGE    Function   Menu. 

F.5).  Again,  let  it  be  emphasised  that  it  is  important  tc 
have  a  plan  for  the  cverall  target  database  since  it  is  not 
possible  to  gracefuly  go  backward  in  sequential  time  as  a 
target  database  is  developed.  Also,  it  is  again  recommended 
to  the  user  to  obtain  a  print  of  the  Target- List  as  seen  as 
you    return   tc  the   Main  Menu. 
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C.       BON    STATIC    MODEL 

The  SEY-1A  Controller  Model  Simulator  "SPYTEST.CMD"  is 
provided  as  a  tool  to  test  the  Radar  Signal  Processor 
Interface  Simulation  Static  Model.  "SPYTEST.CMD"  is  just  a 
simple  eventcount  and  sequencer  module.  It  contains  a  delay 
loop  to  simulate  the  time  between  the  receipt  of  a  "raw 
data"  message  from  the  Signal  Processor  Interface,  the 
subsequent  processing  of  the  target  data,  and  the  resultant 
dwell      command    message      generated     to      the   Signal      Processor 


===    RSP    STATIC    MODEL    === 
version    1.0    June   83 


At   this    point   you    should    have   created 
a    database  and  are   now   ready   to  run 
the    Static  Model. 


===    STATIC    MODEL    MENU    === 
TEST   run    the    simulation 
QUIT   and    return  to   main   menu 
enter    1-2  and   <cr>: 


\l\ 


Figure   F.6        STATIC    MODEL   Function   Menu. 

Interface.  The  delay  loop  is  arbitrarily  configured  at  this 
time,  and  the  user  should  consider  contriving  a  delay  that 
more  closely  represents  the  turnaround  time  the  SPY-1A 
system   should   provide.  When    entering    the   test      mode,      the 

user  will  be  prompted  to  "Load  SPYTEST.CMD  from  another 
system    CBT/SEC.       When   complete,    enter    "0"<cr>    to    begin    ". 

When  the  SPY-1A  Controller  Simulator  has  been  initiated, 
the  Static  Model  will  begin  operation  after  the  user  has 
typed    "0<cr>".       The    display    for   the    Static    Model    is    shown    in 
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===    RSP    STATIC   MODEL    SIMULATION    =« 
TIME:  ENDTIME: 


Figure  F.7  STATIC  MODEL  Display- 
Fig.  F.7,  and  provides  the  user  with  only  a  minimum  ammount 
cf  information  to  determine  the  progress  and  speed  of  execu- 
tion for  the  SPY-1A  Model.  Since  the  Static  Model  and  its 
inherent  display  functions  will  be  part  of  the  timed  data 
garhered  by  the  user,  it  is  recommended  that  the  SPY-1A 
Contrcller  Simulator  te  utilized  to  measure  the  Static  Model 
time.  The  measured  Static  Model  run  time  can  be  used  in 
future  rur-time  testing  of  the  NPS  SPY-1A  Controller  Model 
to    determine  net   SPY-1A   Controller  Model   achievable   sueed. 
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